Ada memory management seems slow

Ada memory management seems slow

[Makhno]

Hello,
I have been given some Ada software to use, and it uses some linked list 
structures. I compiled it using Win32 GNAT.
These structures are dynamically allocated, and when they are de-allocated, 
it takes up a almost 2 seconds of computing time, even though this is a fast 
PC and the actual memory they use doesn't appear to be much (seems less than 
1mb according to the task manager).

I was wondering what options are available for memory management, or whether 
I am inadvertently using a 'slow' mode.

Thank you. 

Re: Ada memory management seems slow

[Robert A Duff]

"Makhno" <root@127.0.0.1> writes:

> Hello,
> I have been given some Ada software to use, and it uses some linked list 
> structures. I compiled it using Win32 GNAT.
> These structures are dynamically allocated, and when they are de-allocated, 
> it takes up a almost 2 seconds of computing time, even though this is a fast 
> PC and the actual memory they use doesn't appear to be much (seems less than 
> 1mb according to the task manager).
> 
> I was wondering what options are available for memory management, or whether 
> I am inadvertently using a 'slow' mode.

It's impossible to know what the problem is without looking at the
source code.

You can write your own storage management code -- look up package
Storage_Pools in the RM.  For example, you can arrange to deallocate
large chunks of memory all at once, rather than deallocating each list
element individually -- this is called "region based memory management"
or "arena based memory management".

Sometimes deallocation is triggered by finalization.  This can be very
convenient, but most compilers have quite a lot of run-time overhead for
finalization, so that could be part of your problem.  Finalizing a
million objects could take a fairly long time.  I believe there's a
pragma in GNAT to turn off finalization if the program is about to exit
anyway; I don't remember what it's called.

- Bob

Re: Ada memory management seems slow

[Anh Vo]

I would like give some prove to what Robert already said. It took ~0.3
second to allocate and deallocate a more than 6 million integer using
my own storage pool design. In addition, it took about 1.3 second using
heap memory using regular access type. I am using 2.4 GHz PC running
GNATMAKE GPL 2005 (20050729).

AV

Re: Ada memory management seems slow

[Martin Krischik]

Makhno wrote:

> I have been given some Ada software to use, and it uses some linked list
> structures. I compiled it using Win32 GNAT.
> These structures are dynamically allocated, and when they are
> de-allocated, it takes up a almost 2 seconds of computing time, even
> though this is a fast PC and the actual memory they use doesn't appear to
> be much (seems less than 1mb according to the task manager).

GNAT uses malloc and free from the C library  for memory management - so
performace is the same as with C. Only with C nobody measures the
performance - people just expect malloc and free to be as fast as possible.

> I was wondering what options are available for memory management, or
> whether I am inadvertently using a 'slow' mode.

Well there is indeed a memory debug option - but its off by default.

Martin

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

Re: Ada memory management seems slow

[Makhno]

> GNAT uses malloc and free from the C library  for memory management - so
> performace is the same as with C. Only with C nobody measures the
> performance - people just expect malloc and free to be as fast as 
> possible.

I find this difficult to believe - I have experience of using free() in C, 
and unless the lists are far bigger than I think they are, C is nowhere near 
as slow as this.
Is there any way I can check precisely what Ada is using? The program is 
calling something called FREE which is defined as some sort of deallocator 
called Ada.Unchecked_Deallocation

>> I was wondering what options are available for memory management, or
>> whether I am inadvertently using a 'slow' mode.
>
> Well there is indeed a memory debug option - but its off by default.

I'm using gnatmake with -O3.

Re: Ada memory management seems slow

[Alex R. Mosteo]

Makhno wrote:
>>GNAT uses malloc and free from the C library  for memory management - so
>>performace is the same as with C. Only with C nobody measures the
>>performance - people just expect malloc and free to be as fast as 
>>possible.
> 
> 
> I find this difficult to believe - I have experience of using free() in C, 
> and unless the lists are far bigger than I think they are, C is nowhere near 
> as slow as this.
> Is there any way I can check precisely what Ada is using? The program is 
> calling something called FREE which is defined as some sort of deallocator 
> called Ada.Unchecked_Deallocation

I'd look in what others have indicated: Is Finalization involved? How 
many objects are you finalizing? Is there some expensive computation 
taking place there?

Other than that, you could use some profiler. People has reported mixed 
success with gprof (look for past threads in this group); valgrind could 
be of use too.

>>>I was wondering what options are available for memory management, or
>>>whether I am inadvertently using a 'slow' mode.
>>
>>Well there is indeed a memory debug option - but its off by default.
> 
> 
> I'm using gnatmake with -O3.
> 
> 

Re: Ada memory management seems slow

[Martin Dowie]

>> I'm using gnatmake with -O3.

Try -O2 instead. I've heard that -O3 should be used with care and can lead
to some counter intuitive results!

Cheers

-- Martin

Re: Ada memory management seems slow

[Stephen Leake]

"Martin Dowie" <martin.dowie@baesystems.com> writes:

>>> I'm using gnatmake with -O3.
>
> Try -O2 instead. I've heard that -O3 should be used with care and can lead
> to some counter intuitive results!

Yes. AdaCore's official position is that "-03 contains experimental
and dangerous optimizations, and is not recommended".

-- 
-- Stephe

Re: Ada memory management seems slow

[Gautier Write-only]

Martin Dowie wrote:

> >> I'm using gnatmake with -O3.
> 
> Try -O2 instead. I've heard that -O3 should be used with care and can lead
> to some counter intuitive results!

It does - especially by inlining too much.
Better to add Pragma Inline(...)'s manually and test.
______________________________________________________________ 
Gautier     --     http://www.mysunrise.ch/users/gdm/index.htm 
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm 

NB: For a direct answer, e-mail address on the Web site!

Re: Ada memory management seems slow

[Georg Bauhaus]

Gautier Write-only wrote:
> Martin Dowie wrote:
> 
> 
>>>>I'm using gnatmake with -O3.
>>
>>Try -O2 instead. I've heard that -O3 should be used with care and can lead
>>to some counter intuitive results!
> 
> 
> It does - especially by inlining too much.
> Better to add Pragma Inline(...)'s manually and test.

and combine -gnatn with -O2.

Re: Ada memory management seems slow

[Simon Wright]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> Gautier Write-only wrote:
>> Martin Dowie wrote:
>> 
>>>>>I'm using gnatmake with -O3.
>>>
>>>Try -O2 instead. I've heard that -O3 should be used with care and can lead
>>>to some counter intuitive results!
>> It does - especially by inlining too much.
>> Better to add Pragma Inline(...)'s manually and test.
>
> and combine -gnatn with -O2.

GNAT (now) has pragma Inline_Always.

Re: Ada memory management seems slow

[tmoran]

Can you compile and run with a different Ada compiler for comparison?

Re: Ada memory management seems slow

[Martin Krischik]

Makhno wrote:

>> GNAT uses malloc and free from the C library  for memory management - so
>> performace is the same as with C. Only with C nobody measures the
>> performance - people just expect malloc and free to be as fast as
>> possible.
> 
> I find this difficult to believe - I have experience of using free() in C,
> and unless the lists are far bigger than I think they are, C is nowhere
> near as slow as this.

Do you use Ada.Finalization? Ada.Finalization can eat performace when
compared with C. C does not have automatic finalisation.

> Is there any way I can check precisely what Ada is using? The program is
> calling something called FREE which is defined as some sort of deallocator
> called Ada.Unchecked_Deallocation

You can look up the source code. From you installation directory you should
have something like:

.../lib/gcc/x86_64-unknown-linux-gnu/3.4.5/adainclude

Where you find almost the full sources for all gnat library functions. Look
at s-crtl.ads where the actual malloc call is.

>>> I was wondering what options are available for memory management, or
>>> whether I am inadvertently using a 'slow' mode.
>>
>> Well there is indeed a memory debug option - but its off by default.
> 
> I'm using gnatmake with -O3.

In which case GNAT will automaticy inline if possible - using the sources
mentioned above ;-)

Well, I have a cold - maybe someone else can elaborate on finalisation.

Martin

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

Re: Ada memory management seems slow

[Robert A Duff]

"Makhno" <root@127.0.0.1> writes:

> > GNAT uses malloc and free from the C library  for memory management - so
> > performace is the same as with C. Only with C nobody measures the
> > performance - people just expect malloc and free to be as fast as 
> > possible.
> 
> I find this difficult to believe - I have experience of using free() in C, 
> and unless the lists are far bigger than I think they are, C is nowhere near 
> as slow as this.
> Is there any way I can check precisely what Ada is using?

You can dump out the assembly language produced by the compiler.
You can read the run-time library sources.
You can single-step through the code using gdb.

>...The program is
> calling something called FREE which is defined as some sort of deallocator 
> called Ada.Unchecked_Deallocation

Yeah, that's the usual way to deallocate things in Ada --
Unchecked_Deallocation is pretty-much analogous to free() in C.

I'm pretty sure Unchecked_Deallocation uses the same "free()" that C
code would use.  It's not very efficient (I've written more
efficient allocators), but it's not horrible.

What makes you think that memory deallocation is the problem?
Perhaps some other code is causing the problem.
I mentioned finalization in another post.
Also, Ada needs to do some locking around memory [de]allocation
primitives; that might be something to look into.

- Bob