Memory limits in Ada where Fortran has none

Memory limits in Ada where Fortran has none

[braver]

I'm interoperating with a Fortran algorithm using a very large array of
integers:

      PARAMETER (NMAX=100000000) ! a hundred million
      DIMENSION ND(NMAX)
C ...

In Ada, I declared it as

   type Intarray is array (Positive range <>) of Integer;

   ND: Intarray(1..NMAX); -- (1)

-- then I get a STORAGE_ERROR right about NMAX is 2_000_000.

If I do, instead,

   type Intarray_Ptr is access Intarray;
   ND: Intarray_Ptr;
-- ...
   ND := new Intarray(1..NMAX);

-- I get the STORAGE_ERROR right about NMAX=256*1024*256, which, given
the size of Integer as 32 bits, shows the limit of the _total heap size
in bits_ as the max 32 value.  So it leaves me with a 256 MB heap size,
or about 67_108_864 elements -- ~2/3 of what I need.
How do I increase the heap size, if at all possible, or the main memory
size?

In GNU f77, the array allocates and works fine, so I thought to import
it with pragma Import, just as I do with subroutines -- but the linkage
name for a variable in MAIN__ is not showing in mn main.o!  Any idea
how to link/import a GNU f77 _variable_ from GNAT?

Overall, Ada being the language for large systems, I found it
surprising that Fortran can allocate enough arrays to fill in my
memory, or even take up virtual memory, while Ada raises
STORAGE_ERRORs!  I'd like to simply use (1), as in Fortran, and be done
with it...

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[Jeff C]

braver wrote:
> I'm interoperating with a Fortran algorithm using a very large array of
> integers:
> 
>       PARAMETER (NMAX=100000000) ! a hundred million
>       DIMENSION ND(NMAX)
> C ...
> 
> In Ada, I declared it as
> 
>    type Intarray is array (Positive range <>) of Integer;
> 
>    ND: Intarray(1..NMAX); -- (1)
> 
> -- then I get a STORAGE_ERROR right about NMAX is 2_000_000.
> 

If you are doing that in a procedure (including the main procedure) then
ND is being allocated on the Stack not the heap. If ND were inside of a 
package then you should get the same results that you got with your 
pointer approach.


As for the pointer approach also being "too small" it is not that your 
heap is limited. You can declare (via pointers or package level 
variables) lots of objects of your max size. You just can't have a 
single variable with a 'size that exceeds the 32 bit limit.

To be precise here this is not "and Ada thing". This is one particular 
vendor (guessing GCC) decision about an implementation defined 
limit...And I agree it is an unfortunate choice that was probably 
reasonable a few years ago and has now become too small.

Re: Memory limits in Ada where Fortran has none

[braver]

Ok, I can declare TWO of them in a package,  each up to ~67 million
integers, but I need to use them as one -- and pass as one to Fortran.
I guess I could use a record and pack it?...  I wish g77 would tell me
how to link to its variables!  That can be a solution, declaring large
arrays in another language and importing them...

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[Martin Krischik]

Hi,

> Ok, I can declare TWO of them in a package,  each up to ~67 million
> integers, but I need to use them as one -- and pass as one to Fortran.
> I guess I could use a record and pack it?...  I wish g77 would tell me
> how to link to its variables!  That can be a solution, declaring large
> arrays in another language and importing them...

An access function might be the solution here.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Memory limits in Ada where Fortran has none

[braver]

My working solution is probably what you mean by access function.

I could import a Fortran variable from a subroutine by compiling the
Fortran module with -fno-automatic, but then I'd still have to declare
it in Ada first -- and hit the size limit, or try to turn off index
checking, which is bothersome.

So instead, I keep the array in Fortran.  And as Ada's array access was
designed to look the same as a (memoized) function, Fortran being the
same, I declare, in Fortran,

      FUNCTION ND(I)
      COMMON /NDD/NNDD
      DIMENSION ND(PARAMETER MMAX=100 000 000)
      ND = NNDD(I)
      RETURN
      END

and in Ada,

   function ND(I: Positive) return Integer;

   pragma Import (Fortran, ND,
                    External_Name=> "ND",
                    Link_Name=> "nd_"
        );

   pragma Inline(ND);

-- import ND, inline it, et voila!  I create a package Lord_Fortran to
do the importing/inlining, and just with/use it.  It is actually
surprisingly fast even without turning off range checking.

>From now on, I allocate data arrays longer than 256*256*1024 elements
in Fortran.  As people guessed correctly, I use GNAT -- what else can I
do on Linux, given I can't find a downloadable/trial copy of Rational
Apex, even though IBM took over it?  As for patches -- anyone heard of
a 32-bit 'Size / 'Storage_Size patch to GNAT?

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[Jeff C]

braver wrote:

>>From now on, I allocate data arrays longer than 256*256*1024 elements
> in Fortran.  As people guessed correctly, I use GNAT -- what else can I
> do on Linux, given I can't find a downloadable/trial copy of Rational
> Apex, even though IBM took over it?  As for patches -- anyone heard of
> a 32-bit 'Size / 'Storage_Size patch to GNAT?
> 
> Cheers,
> Alexy
> 

IBM is still selling Apex (IBM Rational Ada Developer) and they do 
support Linux

http://www-306.ibm.com/software/awdtools/developer/embedded/enterprise/index.html

but I think that you are correct that there is no trial copy. If you 
work for a company that actually might buy it I am sure that a IBM sales 
rep will set you up with an evaluation copy.

I don't know why they don't make a trial version available. Many of the 
bigger heritage Rational tools still don't have trial versions (e.g. 
Clearcase).

Perhaps you could see if AdaCore would be willing to upgrade 'size in 
order to get you as a supported customer.

Re: Memory limits in Ada where Fortran has none

[Craig Carey]

I guess that the FORTRAN was leaving too little memory for the Ada 95
 program.


On 6 Mar 2005 08:14:21 -0800, "braver" <deliverable@gmail.com> wrote:

>My working solution is probably what you mean by access function.
...
>>From now on, I allocate data arrays longer than 256*256*1024 elements
>in Fortran.  As people guessed correctly, I use GNAT -- what else can I
>do on Linux, given I can't find a downloadable/trial copy of Rational
>Apex, even though IBM took over it?  As for patches -- anyone heard of
>a 32-bit 'Size / 'Storage_Size patch to GNAT?


I guess that allocating memory on the Ada 95 side is not needed.

Maybe a thin pointer to a not allocated huge array could be used. E.g.: 

   type AA is array (Positive range <>) of ...;
   type Huge is array AA (Positive)
   Type Huge_Ptr is access Huge;
   F : Heap_Array_Ptr := new ....    --  A fat array double pointer
   X : Huge_Ptr := unchecked conversion from (F (F'First));
      --  Upper bound range checking on indexing X is absent

When importing a FORTRAN array into Ada 95, there is a choice of:
* an allocated array, or
* a pointer to a not allocated array. If the size is not known then it
   can be an array that is too large to allocate.

A pointer to the 1st element of any array including a FORTRAN array is
converted to a super large array. That zaps the upper bound index
checking.

So adding pointers can be avoided using indexing.
(If not, then GNAT source code of the gcc.gnu.org package
"Interfaces.C.Pointers" could be adapted.)

Also, there is the GNAT linker options allowing the stack size and heap
 size to be altered. They are described in the GNAT User's Guide:

gnatmake ... -largs --stack=0x30000"

The GNAT Users guide says:

$ gnatlink hello -Xlinker --stack=0x10000,0x1000

"This set the stack reserve size to 0x10000 bytes and the stack commit
 size to 0x1000 bytes."

$ gnatlink hello -Xlinker --heap=0x10000,0x1000
"This set the heap reserve size to 0x10000 bytes and the heap commit size
 to 0x1000 bytes."


On 6 Mar 2005 14:13:13 -0800, Gerald wrote:
...
>You should dynamically allocate the big array:
...
Hmm


--  Craig Carey <research@ijs.co.nz>    Avondale, Auckland, New Zealand
--  Fairness checklist: http://www.ombudsman.on.ca/pdf/fairness_stds.pdf
--  Ada 95 mailing lists: http://www.ijs.co.nz/ada_95.htm

Re: Memory limits in Ada where Fortran has none

[braver]

Thanks, Craig, it's nice!  I thought along these lines -- declare an
array in Ada, import it from Fortran, and simply turn off the upper
limit check via pragma/command line switch.  Like:

   ND: Intarray(1..NMAX); -- don't care what NMAX is!
   Pragma Import(Fortran, ND, "nd_");

Now compile it with -gnatp and use whatever index...   And if it's in a
package, may even avoid using the heap...  Didn't check this one, but
seems OK to me...

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[braver]

Now, this is an interesting experiment:

Fortran:
C-----
      PARAMETER (NMAX=100 000 000)
      COMMON /CA/A
      INTEGER A
      DIMENSION A(NMAX)
      END
C-----

Ada: we have a package Lord_Fortran and the main procedure Import:

package Lord_Fortran is
   A: array (Positive range 1..67_000_000) of Integer;
   pragma Import(Fortran, A, "ca_");
   pragma Suppress(Index_Check, On=> A);
end Lord_Fortran;

with Text_IO; use Text_IO;
with Lord_Fortran; use Lord_Fortran;
procedure Import is
   package IO_Integer is new Integer_IO(Integer); use IO_Integer;

   NMAX: constant Positive := 100_000_000;

   S: Natural := 0;

   pragma Suppress(All_Checks, A);

begin
   Put_Line("Lord Fortran, we bow before thee!");

   for I in 1..NMAX loop
      A(I) := I;
      if I mod 1_000_000 = 0 then
         Put('.');
         -- Put(I);
      end if;
   end loop;
   New_Line;
   Put_Line("Allright!");

   S := A(68_000_000);

   Put(Integer'Image(S));
   New_Line;
end Import;

Depending on the index value at (1), I get the following results...
When running as above:

alexy@angle:/bk/ada/import > ./import
Lord Fortran, we bow before thee!
....................................................................................................
Allright!

raised CONSTRAINT_ERROR : import.adb:25

(There's a hundred dots, as expected!)

If the index is NMAX, then (same as above but the exception):
...
Allright!

raised STORAGE_ERROR : stack overflow (or erroneous memory access)

When 67_000_000, prints it.  Strangely, doesn't come close enough to
67_108_864...

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[braver]

Duh/Da.  Solved by replacing 67_000_000 in Lord_Fortran by 100_000_000.

This is the easiest solution.  Since Fortran comes with GCC, one can
simply declare large arrays in it and import them into Ada where 32-bit
limit is a problem.

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[Stephen Leake]

"braver" <deliverable@gmail.com> writes:

> Ok, I can declare TWO of them in a package,  each up to ~67 million
> integers, but I need to use them as one -- and pass as one to Fortran.
> I guess I could use a record and pack it?...  I wish g77 would tell me
> how to link to its variables!  That can be a solution, declaring large
> arrays in another language and importing them...

Ask your compiler vendor. There is probably a compiler switch that
affects this. Or perhaps they can provide a patch.

-- 
-- Stephe

Re: Memory limits in Ada where Fortran has none

[Martin Krischik]

braver wrote:

> Overall, Ada being the language for large systems, I found it
> surprising that Fortran can allocate enough arrays to fill in my
> memory, or even take up virtual memory, while Ada raises
> STORAGE_ERRORs!  I'd like to simply use (1), as in Fortran, and be done
> with it...

It is a problem of the GNAT compiler. GNAT uses 32 bit Integer for the 'Size
attribute. And 'Size is the size in bit - not byte. A few years ago that
was fine but now you a the 2nd person in half a year to hit that limit.

Also, GNAT unlike other Ada compiler won't use heap memory unless beeing
told to (via the keyword new) so the array is either static or stack - both
might be limited by the operating system.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Memory limits in Ada where Fortran has none

[Gerald]

"braver" <deliverable@gmail.com> wrote in message news:<1110070479.250902.220540@l41g2000cwc.googlegroups.com>...
> I'm interoperating with a Fortran algorithm using a very large array of
> integers:
> 
>       PARAMETER (NMAX=100000000) ! a hundred million
>       DIMENSION ND(NMAX)
> C ...
> 
> In Ada, I declared it as
> 
>    type Intarray is array (Positive range <>) of Integer;
> 
>    ND: Intarray(1..NMAX); -- (1)
> 
> -- then I get a STORAGE_ERROR right about NMAX is 2_000_000.
> 
> If I do, instead,
> 
>    type Intarray_Ptr is access Intarray;
>    ND: Intarray_Ptr;
> -- ...
>    ND := new Intarray(1..NMAX);
> 
> -- I get the STORAGE_ERROR right about NMAX=256*1024*256, which, given
> the size of Integer as 32 bits, shows the limit of the _total heap size
> in bits_ as the max 32 value.  So it leaves me with a 256 MB heap size,
> or about 67_108_864 elements -- ~2/3 of what I need.
> How do I increase the heap size, if at all possible, or the main memory
> size?
> 
> In GNU f77, the array allocates and works fine, so I thought to import
> it with pragma Import, just as I do with subroutines -- but the linkage
> name for a variable in MAIN__ is not showing in mn main.o!  Any idea
> how to link/import a GNU f77 _variable_ from GNAT?
> 
> Overall, Ada being the language for large systems, I found it
> surprising that Fortran can allocate enough arrays to fill in my
> memory, or even take up virtual memory, while Ada raises
> STORAGE_ERRORs!  I'd like to simply use (1), as in Fortran, and be done
> with it...
> 
> Cheers,
> Alexy

You should dynamically allocate the big array:

with Ada.Text_IO;
use  Ada.Text_IO;

procedure mtest is

NMAX: constant := 3_000_000;

type Intarray is array (Positive range <>) of Integer;
type Intarray_Ptr is access all Intarray;

ND: Intarray_Ptr;
s : Long_Integer;

begin

ND:=new Intarray(1..NMAX);

for i in ND'range loop
    ND(i):=1;
end loop;

s:=0;
for i in ND'range loop
s:=s+Long_Integer(ND(i));
end loop;

Put(Long_Integer'Image(s));

end mtest;
./mtest
 3000000

Re: Memory limits in Ada where Fortran has none

[Dr. Adrian Wrigley]

Hi!

This GNAT problem is coming up more frequently now with
more people wanting to use their 32-bit systems to the full :(

I regularly declare and use arrays in Ada which are 1.9GB, and
map directly to files (via POSIX mmap).  This is amazingly
fast for access to databases I need because I can directly
access all the elements in memory.

Unfortunately, my data sets ideally would be around 4-5GB, but
my Linux box wont mmap more than 2GB :(

The main caveats (IIRC) are:

Don't use 'Size type attributes on large records/arrays
Only use access values to the data
accessing record elements whose offset is > 256MB may be a problem(?) 

It's a big nuisance, because you can end up with programs which
compile OK, but fail at run-time.

I'm hoping someone will build an Athlon64 implementation of GNAT which
can make use of 64-bit access values.  I'm sure it will happen one day,
because 64-bit PCs will soon be ubiquitous, and the 256MB will become
a total embarrassment to the GNAT/Ada community.

Adrian
-- 
Dr. Adrian Wrigley, Cambridge, UK.

Re: Memory limits in Ada where Fortran has none

[braver]

Adrian -- sounds extremely interesting!  Can you please provide an
example of using mmap with a 1.9 GB array from Ada?

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[Dr. Adrian Wrigley]

On Sun, 06 Mar 2005 16:31:25 -0800, braver wrote:

> Adrian -- sounds extremely interesting!  Can you please provide an
> example of using mmap with a 1.9 GB array from Ada?

I have sent you a couple of (scrappy) code samples.  One uses a
sentinel(?) to find where in memory the end of a record is when
GNAT record size and attributes are exceeded.  The other uses
Florist memory mapping to access arrays up to the mmap limit
(just under 2GB on my system (:())

Let us know how you get on!
-- 
Adrian

Re: Memory limits in Ada where Fortran has none

[Martin Krischik]

Dr. Adrian Wrigley wrote:

> I'm hoping someone will build an Athlon64 implementation of GNAT which
> can make use of 64-bit access values.  I'm sure it will happen one day,
> because 64-bit PCs will soon be ubiquitous, and the 256MB will become
> a total embarrassment to the GNAT/Ada community.

I have got a AMD 64 GNAT right here. Works fine as long as you remember to
use -fPIC. Of course any program relying on access types and 'Address
beeing 32 bit will fail - most notably this includes trace utilities.

In fact the newer GNATs now has a new System.Address_Image package for that
reason.

http://en.wikibooks.org/wiki/Programming:Ada:Packages:System.System.Address_Image

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Memory limits in Ada where Fortran has none

[Dr. Adrian Wrigley]

On Mon, 07 Mar 2005 10:41:30 +0100, Martin Krischik wrote:

> I have got a AMD 64 GNAT right here. Works fine as long as you remember to
> use -fPIC. Of course any program relying on access types and 'Address
> beeing 32 bit will fail - most notably this includes trace utilities.

Presumably this is compatible with the LP64 model of the universe with
C longs and pointers being 64-bit, and ints at 32 bits(?)
GNAT "Integer"s stay at 32 bits?

Did you build the compiler yourself? (can it be cross-compiled with
the x86 GNAT?) What about third party GNAT packages (Florist?
GtkAda? PolyORB?)  Which OS version?

I'd love to move to 64 bit systems, but the cost and risk of getting
new hardware and (probably) building all the libraries still puts me off!

A success story from a c.l.a 'local' would probably be enough to
make me have a go.

Adrian
-- 
Dr. Adrian Wrigley, Cambridge, UK.

Re: Memory limits in Ada where Fortran has none

[Martin Krischik]

Dr. Adrian Wrigley wrote:

> On Mon, 07 Mar 2005 10:41:30 +0100, Martin Krischik wrote:
> 
>> I have got a AMD 64 GNAT right here. Works fine as long as you remember
>> to use -fPIC. Of course any program relying on access types and 'Address
>> beeing 32 bit will fail - most notably this includes trace utilities.

> Presumably this is compatible with the LP64 model of the universe with
> C longs and pointers being 64-bit, and ints at 32 bits(?)
> GNAT "Integer"s stay at 32 bits?

Yes, that's the way it works. And so an Unchecked_Convertion from Address to
Integer will fail now. 

> Did you build the compiler yourself?

Yes.

> (can it be cross-compiled with 
> the x86 GNAT?)

In theory yes but is is easier to compile with the targes OS.

> What about third party GNAT packages (Florist? 
> GtkAda? PolyORB?)  Which OS version?

Most Libs work, but from those you named I have tried only:
PolyORB and it works fine exept for -fPIC (shared libs).

> I'd love to move to 64 bit systems, but the cost and risk of getting
> new hardware and (probably) building all the libraries still puts me off!

With AMD 64 you can allways install both 32 bit and 64 bit Linux parallel.

> A success story from a c.l.a 'local' would probably be enough to
> make me have a go.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Memory limits in Ada where Fortran has none

[Robert A Duff]

"braver" <deliverable@gmail.com> writes:

> I'm interoperating with a Fortran algorithm using a very large array of
> integers:
> 
>       PARAMETER (NMAX=100000000) ! a hundred million
>       DIMENSION ND(NMAX)
> C ...
> 
> In Ada, I declared it as
> 
>    type Intarray is array (Positive range <>) of Integer;
> 
>    ND: Intarray(1..NMAX); -- (1)
> 
> -- then I get a STORAGE_ERROR right about NMAX is 2_000_000.

The following works for me:

package Test_Pkg is
    X: array (1..400_000_000) of Integer := (others => 999);
end Test_Pkg;

with Test_Pkg; use Test_Pkg;
with Text_IO; use Text_IO;
procedure Test is
begin
    Put_Line(Integer'Image(X(X'Last)));
end Test;

I'm using GNATPRO version 5.03a on a windows machine with about 1 GB of
RAM.  It takes about 2 minutes to run.  And I can hear the disk clicking
wildly!  But I don't get Storage_Error, and it prints 999 as expected.

- Bob

Re: Memory limits in Ada where Fortran has none

[braver]

Bob -- how different is GNATPro from GCC GNAT?  And how much is it?
:-)

Once I'm on the subject, anyone has good experience with Rational on
Linux?
I.e., is there any reason to do anything but GNAT -- which is the only
thing we know is definitely here indefinitely?

Cheers,
Alexy

Re: Memory limits in Ada where Fortran has none

[Robert A Duff]

"braver" <deliverable@gmail.com> writes:

> Bob -- how different is GNATPro from GCC GNAT?  And how much is it?
> :-)

I don't know.  Talk to AdaCore.  GNATPro is gcc GNAT, but I probably
have a newer version, which will eventually be released publicly.  You
basically pay AdaCore for support, which is quite good.  Here I am
advertising my company's competitor.  SofCheck has no Ada compiler for
Linux at the moment, but we do sell an Ada-to-C translator that can be
used on any machine that supports C, including Linux.  (And our support
is quite good, too, if I do say so myself.  ;-))

Allocating large arrays should work just as well in Ada as it does in
Fortran.  If you're having trouble with it in Ada, then either you're
doing something wrong, or the compiler has a bug.  You can report bugs
to AdaCore even if you don't have a support contract.

> Once I'm on the subject, anyone has good experience with Rational on
> Linux?

Rational Ada is also a good compiler.  I've used it, but not on Linux.

- Bob
  Vice President of Engineering
  SofCheck, Inc.

Re: Memory limits in Ada where Fortran has none

[Martin Krischik]

Robert A Duff wrote:

> "braver" <deliverable@gmail.com> writes:
> 
>> Bob -- how different is GNATPro from GCC GNAT?  And how much is it?
>> :-)

GNATPro is supported.

> I don't know.  Talk to AdaCore.  GNATPro is gcc GNAT, but I probably
> have a newer version, which will eventually be released publicly.

AFAIK the AdaCore commits there sources almost directly to the gcc to avoid
large merging sessions.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Memory limits in Ada where Fortran has none

[Dr. Adrian Wrigley]

On Sun, 06 Mar 2005 19:05:21 -0500, Robert A Duff wrote:

> The following works for me:
> 
> package Test_Pkg is
>     X: array (1..400_000_000) of Integer := (others => 999);
> end Test_Pkg;
> 
> with Test_Pkg; use Test_Pkg;
> with Text_IO; use Text_IO;
> procedure Test is
> begin
>     Put_Line(Integer'Image(X(X'Last)));
> end Test;

I am very wary of a test like this because GNAT sometimes
silently accesses the wrong element of very large data, if I
remember correctly. A correctly written program can (and did!)
thus fail catastrophically.  Large records in particular are
suspect (on GNAT 3.15p, x86). (I have no test case to hand
at the moment).  I don't know if it is affected by -gnato
and default absence of overflow checking.

A more comforting test would place a *different* value at
each location, and check they are all correct!
-- 
Dr. Adrian Wrigley, Cambridge, UK.

Re: Memory limits in Ada where Fortran has none

[Craig Carey]

On Tue, 08 Mar 2005 11:24:42 GMT, "Dr. Adrian Wrigley" wrote:
>On Sun, 06 Mar 2005 19:05:21 -0500, Robert A Duff wrote:
...
>I am very wary of a test like this because GNAT sometimes
>silently accesses the wrong element of very large data, if I
>remember correctly. A correctly written program can (and did!)
>thus fail catastrophically.  Large records in particular are
>suspect (on GNAT 3.15p, x86). (I have no test case to hand
...

It might be a bug in the memory paging code. What's the OS ?.

The Internet does have reports on how Linux gets bytes wrong when
copying files across a disk. Maybe the filesystem the paging is
done to, is a possible cause.

--  Craig

Re: Memory limits in Ada where Fortran has none

[Craig Carey]

On Wed, 09 Mar 2005 16:39:34 +1300, Craig Carey wrote:
>On Tue, 08 Mar 2005 11:24:42 GMT, "Dr. Adrian Wrigley" wrote:
>>On Sun, 06 Mar 2005 19:05:21 -0500, Robert A Duff wrote:
>...
>>I am very wary of a test like this because GNAT sometimes
>>silently accesses the wrong element of very large data, if I
>>remember correctly. A correctly written program can (and did!)
>>thus fail catastrophically.  Large records in particular are
>>suspect (on GNAT 3.15p, x86). (I have no test case to hand
>...
>

There is the Prime95 Torture Test program that is very sensitive at
detecting mistakes in floating point computations:

  Prime95 v238: http://www.mersenne.org/freesoft.htm

The Tortue Test can easily find summing probems that are too small to
cause crashes of the Windows operating system. Prime95 seems to always
fail to complain about correctly running hardware.

A GNAT integer program (sorting arrays), I have, now runs 50% faster
 after I upgraded from a modern Duron 1600 to a Sempron 2400+ running
 at 2090MHz (10x multiplier).

Integer CPU computation speeds only rising by 24% (said a Sisoft Sandra
program http://www.sisoftware.co.uk/). Raising the voltage from 1.6V to
1.775V gave about 6% extra speed to the integer memory bandwidth speed.

Apparently my GNAT Windows program is limited by the Integer memory
bandwidth or the FSB or whatever, since the Intger memory bandwidth
rose by 55% and Integer CPU speeds ultimately by 33-34%.

>It might be a bug in the memory paging code. What's the OS ?.

It seems to be Linux since the e-mail came from:
  slinuxchip.demon.co.uk.uk.uk>

Of course, a compiler that can't add seems improbable.
I thought the silence about Linux bugs might be due some comment, but
perhaps the most likely thing is that the OS is concealing that the
hardware can't add properly.

Re: Memory limits in Ada where Fortran has none

[Robert A Duff]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> On Sun, 06 Mar 2005 19:05:21 -0500, Robert A Duff wrote:
> 
> > The following works for me:
> > 
> > package Test_Pkg is
> >     X: array (1..400_000_000) of Integer := (others => 999);
> > end Test_Pkg;
> > 
> > with Test_Pkg; use Test_Pkg;
> > with Text_IO; use Text_IO;
> > procedure Test is
> > begin
> >     Put_Line(Integer'Image(X(X'Last)));
> > end Test;
> 
> I am very wary of a test like this because GNAT sometimes
> silently accesses the wrong element of very large data, if I
> remember correctly.

Well, the original poster was complaining that you can't allocate large
amounts of memory in Ada, but you can in Fortran, and I was just trying
to test that.  But, OK, how about this:

package Test_Pkg is
    pragma Elaborate_Body;
    X: array (1..400_000_000) of Integer := (others => 999);
end Test_Pkg;

package body Test_Pkg is
begin
    for I in X'Range loop
        X(I) := Integer'Last - I;
    end loop;
end Test_Pkg;

with Test_Pkg; use Test_Pkg;
with Text_IO; use Text_IO;
procedure Test is
begin
    for I in X'Range loop
        pragma Assert(X(I) = Integer'Last - I); null;
    end loop;
    Put_Line(Integer'Image(X(X'Last)));
end Test;

Works fine, for me.  Takes quite a while to run, of course,
since I don't have that much RAM on my machine.

>... A correctly written program can (and did!)
> thus fail catastrophically.  Large records in particular are
> suspect (on GNAT 3.15p, x86). (I have no test case to hand
> at the moment).  I don't know if it is affected by -gnato
> and default absence of overflow checking.

I guess you should send them a bug report.

> A more comforting test would place a *different* value at
> each location, and check they are all correct!

OK, the above example does that (but it's an array,
not a record).

- Bob

Re: Memory limits in Ada where Fortran has none

[Dr. Adrian Wrigley]

On Wed, 16 Mar 2005 14:51:26 -0500, Robert A Duff wrote:

> "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:
> 
>> I am very wary of a test like this because GNAT sometimes
>> silently accesses the wrong element of very large data, if I
>> remember correctly.
...
>>... A correctly written program can (and did!)
>> thus fail catastrophically.  Large records in particular are
>> suspect (on GNAT 3.15p, x86). (I have no test case to hand
>> at the moment).  I don't know if it is affected by -gnato
>> and default absence of overflow checking.
> 
> I guess you should send them a bug report.

it wasn't convenient at the time (I had to find a fix!)
maybe I will if I have time to make a test case
on a current compiler.

>> A more comforting test would place a *different* value at
>> each location, and check they are all correct!
> 
> OK, the above example does that (but it's an array,
> not a record).

Sorry I raised this without giving a tangible example.
It was to do with locations of elements, and 'Address,
once the 256MB limit is breached.  I wanted to mmap a
large data set, but various things kept breaking.
The solution I found keeps the record under 256M, and avoids
using 'Address on giant arrays.  Works well now...
except I've hit the 2GB limit on the machine's mmap :(

I don't think hardware or OS issues had anything to do with
the issue, since I fixed it with the help of some C code.
The machine also has ECC, and the fault was repeatable.
-- 
Adrian