Using local storage pools...

Using local storage pools...

[Brian Drummond]

I am trying to learn a little about storage pools, with a view to (hopefully)
using local pools to improve the Binary_Trees benchmark in the same way as some
of the faster C benchmarks.

Arguably they cheat : they do not explicitly free each tree node (the "free"
call has been deleted!) but free the entire pool at the end of the loop.
But if that's valid, Ada should be able to do the same.

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html
suggests System.Pool_Local offers a way to do likewise - a pool that is
automatically reclaimed when it goes out of scope.

This turns out to have its own performance problem, but that is another story...

The question(or four)  for now is ... should the following really raise
Storage_Error, i.e. am I doing something silly, and if so, what? 
Or is this a bug in Gnat?

NOTE - using System.Pool_Global.Unbounded_No_Reclaim_Pool 
(commented out) instead of the pool shown, works as expected.

(Tested on GCC4.5.0 and Libre 2010)

- Brian

------------------------------------------------------------------------------------
with System.Pool_Local;
with System.Pool_Global;
with Ada.Unchecked_Deallocation;

procedure pooltest is

   type Node;
   type Treenode is access Node;
   type Node is record
      Left  : Treenode := null;
      Right : Treenode := null;
      Item  : Integer  := 0; 
   end record;

   P : System.Pool_Local.Unbounded_Reclaim_Pool;    
   --P : System.Pool_Global.Unbounded_No_Reclaim_Pool;
   for Treenode'Storage_Pool use P;

   procedure free is new Ada.Unchecked_Deallocation(Node, Treenode);

   TestNode : Treenode;

begin
   Testnode := new Node'(null, null, 1);
   free(Testnode);   
end pooltest;
------------------------------------------------------------------------------------

Re: Using local storage pools...

[Dmitry A. Kazakov]

On Wed, 23 Feb 2011 19:01:22 +0000, Brian Drummond wrote:

> I am trying to learn a little about storage pools, with a view to (hopefully)
> using local pools to improve the Binary_Trees benchmark in the same way as some
> of the faster C benchmarks.

Why don't you implement an arena pool? It is a quite common technique to
allocate nodes of a tree in an arena and never deallocate them explicitly.
I am always use this for the nodes of the abstract syntax tree (AST). Note
that since arena never deallocates, allocation in arena becomes trivial.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Using local storage pools...

[Ludovic Brenta]

Brian Drummond writes:
> I am trying to learn a little about storage pools, with a view to
> (hopefully) using local pools to improve the Binary_Trees benchmark in
> the same way as some of the faster C benchmarks.
>
> Arguably they cheat : they do not explicitly free each tree node (the
> "free" call has been deleted!) but free the entire pool at the end of
> the loop.  But if that's valid, Ada should be able to do the same.
>
> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html
> suggests System.Pool_Local offers a way to do likewise - a pool that
> is automatically reclaimed when it goes out of scope.
>
> This turns out to have its own performance problem, but that is
> another story...
>
> The question(or four) for now is ... should the following really raise
> Storage_Error, i.e. am I doing something silly, and if so, what?  Or
> is this a bug in Gnat?
>
> NOTE - using System.Pool_Global.Unbounded_No_Reclaim_Pool (commented
> out) instead of the pool shown, works as expected.
>
> (Tested on GCC4.5.0 and Libre 2010)
>
> - Brian
>
> ------------------------------------------------------------------------------------
> with System.Pool_Local;
> with System.Pool_Global;
> with Ada.Unchecked_Deallocation;
>
> procedure pooltest is
>
>    type Node;
>    type Treenode is access Node;
>    type Node is record
>       Left  : Treenode := null;
>       Right : Treenode := null;
>       Item  : Integer  := 0; 
>    end record;
>
>    P : System.Pool_Local.Unbounded_Reclaim_Pool;    
>    --P : System.Pool_Global.Unbounded_No_Reclaim_Pool;
>    for Treenode'Storage_Pool use P;
>
>    procedure free is new Ada.Unchecked_Deallocation(Node, Treenode);
>
>    TestNode : Treenode;
>
> begin
>    Testnode := new Node'(null, null, 1);
>    free(Testnode);   
> end pooltest;
> ------------------------------------------------------------------------------------

This looks like a genuine bug at s-pooloc.adb:114.  To trigger the bug,
two conditions must hold simultaneously:

* the pool contains exactly one allocated object.
* the user calls Unchecked_Deallocation on this object.

The buggy code is:

   procedure Deallocate
     (Pool         : in out Unbounded_Reclaim_Pool;
      Address      : System.Address;
      Storage_Size : SSE.Storage_Count;
      Alignment    : SSE.Storage_Count)
   is
      pragma Warnings (Off, Storage_Size);
      pragma Warnings (Off, Alignment);

      Allocated : constant System.Address := Address - Pointers_Size;

   begin
      if Prev (Allocated).all = Null_Address then
         Pool.First := Next (Allocated).all;
         Prev (Pool.First).all := Null_Address; ------- <- Storage_Error
      else
         Next (Prev (Allocated).all).all := Next (Allocated).all;
      end if;

      if Next (Allocated).all /= Null_Address then
         Prev (Next (Allocated).all).all := Prev (Allocated).all;
      end if;

      Memory.Free (Allocated);
   end Deallocate;

This procedure is *not* called by the finalization of the pool, which
simply walks the linked list of nodes and deallocates each one, but does
not modify any nodes.

Because this pool is intended for use without any explicit
Unchecked_Deallocation, I would qualify this bug as minor.

The workaround, in your case, is to simply not do any
Unchecked_Deallocation and let the finalization of the storage pool do
the deallocation.

-- 
Ludovic Brenta.

Re: Using local storage pools...

[Simon Wright]

Brian Drummond <brian_drummond@btconnect.com> writes:

> The question(or four) for now is ... should the following really raise
> Storage_Error, i.e. am I doing something silly, and if so, what?  Or
> is this a bug in Gnat?

Looks to me like a bug in GNAT. I expect it's not been found before
because the point of this pool type is that you *don't* deallocate, but
leave it up to finalization!

I'm not quite clear how we can use this pool in the binary-trees
benchmark, since the rules say you create a class to represent the tree,
which must include the access types, and the storage pool needs to exist
before the access types are used. Perhaps a generic?

Even then, why not just declare an access type in the appropriate scope
and let the compiler figure out how to deallocate storage on scope exit?
(in other words, I don't see why GNAT includes System.Pool_Local in the
first place).

Oh, perhaps it's so that you can actually create such a generic?

Re: Using local storage pools...

[Brian Drummond]

On Wed, 23 Feb 2011 21:42:49 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Wed, 23 Feb 2011 19:01:22 +0000, Brian Drummond wrote:
>
>> I am trying to learn a little about storage pools, with a view to (hopefully)
>> using local pools to improve the Binary_Trees benchmark in the same way as some
>> of the faster C benchmarks.
>
>Why don't you implement an arena pool? It is a quite common technique to
>allocate nodes of a tree in an arena and never deallocate them explicitly.
>I am always use this for the nodes of the abstract syntax tree (AST). Note
>that since arena never deallocates, allocation in arena becomes trivial.

Two reasons : one trivial.

The trivial one: I have never heard of arena pools until now!
But that can be fixed.

The other : the shootout rules explicitly disallow implementing your own pool.
(But importing one from available libraries seems to be permitted; so is there a
suitable candidate?)

- Brian

Re: Using local storage pools...

[Brian Drummond]

On Wed, 23 Feb 2011 21:01:51 +0000, Simon Wright <simon@pushface.org> wrote:

>Brian Drummond <brian_drummond@btconnect.com> writes:
>
>> The question(or four) for now is ... should the following really raise
>> Storage_Error, i.e. am I doing something silly, and if so, what?  Or
>> is this a bug in Gnat?
>
>Looks to me like a bug in GNAT. I expect it's not been found before
>because the point of this pool type is that you *don't* deallocate, but
>leave it up to finalization!

Probably, but the doc doesn't say that freeing is illegal, and the source file
(s_pooloc.ads/b) does have a deallocate routine, so I believe it OUGHT to
work...

I can imagine cases where you free to improve memory footprint, but for whatever
reason you can't (or don't) entirely eliminate memory leaks (so cleanup at a
well-defined point)- in that case, the pool should allow both strategies.

When I created a "local pool" per task, it only left scope on termination,
therefore the memory footprint blew up without freeing. You could argue this was
my programming error.

>I'm not quite clear how we can use this pool in the binary-trees
>benchmark, since the rules say you create a class to represent the tree,
>which must include the access types, and the storage pool needs to exist
>before the access types are used. Perhaps a generic?

Exactly. In my binary_trees experiments I have made the Treenode package a
generic. That part seems to work...

>Even then, why not just declare an access type in the appropriate scope
>and let the compiler figure out how to deallocate storage on scope exit?
>(in other words, I don't see why GNAT includes System.Pool_Local in the
>first place).

I think it's so you can also declare a storage pool along with the
locally-declared access type, (i.e. locally instantiated generic) such that the
entire pool goes out of scope and can be deleted on leaving the scope.

Using the main pool, you would have to deallocate the locally declared access
types but leave the longer-lived objects...

Unfortunately, the current implementation of System.Pool_Local derives from
System.Pool_Global, so it is implemented on the main heap, and its "Finalize"
simply loops over every object freeing them individually. Therefore there is no
performance gain this way...

- Brian

Re: Using local storage pools...

[Brian Drummond]

On Wed, 23 Feb 2011 21:51:20 +0100, Ludovic Brenta <ludovic@ludovic-brenta.org>
wrote:

>Brian Drummond writes:
>> I am trying to learn a little about storage pools, with a view to
>> (hopefully) using local pools to improve the Binary_Trees benchmark in
>> the same way as some of the faster C benchmarks.

>> ------------------------------------------------------------------------------------
>
>This looks like a genuine bug at s-pooloc.adb:114.  To trigger the bug,
>two conditions must hold simultaneously:
>
>* the pool contains exactly one allocated object.
>* the user calls Unchecked_Deallocation on this object.

Good detective work, thanks.

>Because this pool is intended for use without any explicit
>Unchecked_Deallocation, I would qualify this bug as minor.

I believe it should support both strategies (especially since it HAS a
"deallocate")  but I can't argue it's anything other than minor if I'm the first
to find it!

>The workaround, in your case, is to simply not do any
>Unchecked_Deallocation and let the finalization of the storage pool do
>the deallocation.

Which was the original intent.

Thanks for the detective work!

I have been emailed privately, suggesting I report it to Adacore.
Should I also report it to either Debian, or mainstream GCC?

- Brian

Re: Using local storage pools...

[Ludovic Brenta]

Brian Drummond wrote:
> I have been emailed privately, suggesting I report [this bug] to Adacore.
> Should I also report it to either Debian, or mainstream GCC?

To the GCC bugzilla, please. The bug has been confirmed on 4.4.5 and
4.5.2 but my investigation reveals it has been present at least since
2001 (first commit into the public GCC source repository).

--
Ludovic Brenta.

Re: Using local storage pools...

[Dmitry A. Kazakov]

On Wed, 23 Feb 2011 23:55:05 +0000, Brian Drummond wrote:

> The other : the shootout rules explicitly disallow implementing your own pool.

Huh:

   type Nodes_Arena is array (1..<huge-number>) of aliased Node;
   Last_Allocated : Integer := 0;

   function Create return not null access Node is
   begin
      Last_Allocated := Last_Allocated + 1;
      return Nodes_Arena (Last_Allocated)'Access;
   end Create;

This is it an implementation of arena. How can this be disallowed?

> (But importing one from available libraries seems to be permitted; so is there a
> suitable candidate?)

You can try this one:

   http://www.dmitry-kazakov.de/ada/components.htm#7.1

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Using local storage pools...

[Georg Bauhaus]

On 2/24/11 10:26 AM, Dmitry A. Kazakov wrote:
> On Wed, 23 Feb 2011 23:55:05 +0000, Brian Drummond wrote:
>
>> The other : the shootout rules explicitly disallow implementing your own pool.
>
> Huh:
>
>     type Nodes_Arena is array (1..<huge-number>) of aliased Node;
>     Last_Allocated : Integer := 0;
>
>     function Create return not null access Node is
>     begin
>        Last_Allocated := Last_Allocated + 1;
>        return Nodes_Arena (Last_Allocated)'Access;
>     end Create;
>
> This is it an implementation of arena. How can this be disallowed?

"Each program should
...
"allocate, walk, and deallocate many bottom-up binary trees
   * allocate a tree
   * walk the tree nodes, checksum the node items (and maybe deallocate the node)
   * deallocate the tree
...
"Note: these programs are being measured with the default initial heap
  size - the measurements may be very different with a larger initial
  heap size or GC tuning.

"<strong>Please don't implement your own custom memory pool or free list.</>"

"The binary-trees benchmark is a simplistic adaptation of Hans Boehm's GCBench,
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_bench/applet/GCBench.java)
which in turn was adapted from a benchmark by John Ellis and Pete Kovac."


http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees

Re: Using local storage pools...

[Dmitry A. Kazakov]

On Thu, 24 Feb 2011 10:51:51 +0100, Georg Bauhaus wrote:

> On 2/24/11 10:26 AM, Dmitry A. Kazakov wrote:
>> On Wed, 23 Feb 2011 23:55:05 +0000, Brian Drummond wrote:
>>
>>> The other : the shootout rules explicitly disallow implementing your own pool.
>>
>> Huh:
>>
>>     type Nodes_Arena is array (1..<huge-number>) of aliased Node;
>>     Last_Allocated : Integer := 0;
>>
>>     function Create return not null access Node is
>>     begin
>>        Last_Allocated := Last_Allocated + 1;
>>        return Nodes_Arena (Last_Allocated)'Access;
>>     end Create;
>>
>> This is it an implementation of arena. How can this be disallowed?
> 
> "Each program should
> ...
> "allocate, walk, and deallocate many bottom-up binary trees
>    * allocate a tree
>    * walk the tree nodes, checksum the node items (and maybe deallocate the node)
>    * deallocate the tree
> ...
> "Note: these programs are being measured with the default initial heap
>   size - the measurements may be very different with a larger initial
>   heap size or GC tuning.

I see no contradiction. Tree is allocated. It is deallocated too (when
array is destroyed). The stupidity of shootout upheld...

> "<strong>Please don't implement your own custom memory pool or free list.</>"

They seem trying to exclude pool access overhead from the measure, but they
have no working idea how. All these "benchmarks" are measuring things
having nothing or little to do with the manifested objective.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Using local storage pools...

[Brian Drummond]

On Thu, 24 Feb 2011 10:51:51 +0100, Georg Bauhaus
<rm-host.bauhaus@maps.futureapps.de> wrote:

>On 2/24/11 10:26 AM, Dmitry A. Kazakov wrote:
>> On Wed, 23 Feb 2011 23:55:05 +0000, Brian Drummond wrote:

>"Each program should
>...
>"allocate, walk, and deallocate many bottom-up binary trees
>   * allocate a tree
>   * walk the tree nodes, checksum the node items (and maybe deallocate the node)

^^^^^^^^^^^^^^^^^^
 ... aha - I hadn't noticed this clause before...
>   * deallocate the tree
so the strategy of releasing the entire tree is explicitly allowed, releasing
individual nodes is optional. I withdraw any suggestion that the leading
contenders may be cheating.

>"<strong>Please don't implement your own custom memory pool or free list.</>"

So, Thank You Dmitry for "simple components". I'll give them a try.

- Brian

Re: Using local storage pools...

[Robert A Duff]

Brian Drummond <brian_drummond@btconnect.com> writes:

> I have been emailed privately, suggesting I report it to Adacore.

Sorry.  I emailed it by accident.  I meant to post it here.
Here it is:

Brian Drummond <brian_drummond@btconnect.com> writes:

> Arguably they cheat : they do not explicitly free each tree node (the "free"
> call has been deleted!) but free the entire pool at the end of the loop.
> But if that's valid, Ada should be able to do the same.

I don't think it's a "cheat".  This technique is commonly used.
I have used it in various compilers and static analysis tools
and other programs.  Whenever you have large numbers of small
heap-allocated objects that all have roughly the same lifetime,
this technique simplifies the program, makes it more efficient,
and helps avoid dangling pointers.

> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html
> suggests System.Pool_Local offers a way to do likewise - a pool that is
> automatically reclaimed when it goes out of scope.

Pool_Local is not what you want (for efficiency) in this case.
What you want is a pool that allocates large chunks of memory,
and allocates individual small objects within that, and deallocates
the whole thing (all the chunks) at the end (Finalize).
For efficiency, you never call Unchecked_Deallocation.
I'm not sure if such a pool is part of gnatcoll, but if not,
I'll probably add it to gnatcoll someday.

Pool_Local would be more appropriate if the allocated objects are large
(and usually have similar lifetimes).

> This turns out to have its own performance problem, but that is another story...
>
> The question(or four)  for now is ... should the following really raise
> Storage_Error, i.e. am I doing something silly, and if so, what? 
> Or is this a bug in Gnat?

I don't see anything wrong with your code.  If you report it to AdaCore
(report@adacore.com) it will get fixed (at low priority, if you're not a
supported customer).  I'm interested in storage pools -- maybe I'll be
assigned to fix the bug (if it is a bug).

- Bob

Re: Using local storage pools...

[Brian Drummond]

On Thu, 24 Feb 2011 00:03:25 -0800 (PST), Ludovic Brenta
<ludovic@ludovic-brenta.org> wrote:

>Brian Drummond wrote:
>> I have been emailed privately, suggesting I report [this bug] to Adacore.
>> Should I also report it to either Debian, or mainstream GCC?
>
>To the GCC bugzilla, please. The bug has been confirmed on 4.4.5 and
>4.5.2 but my investigation reveals it has been present at least since
>2001 (first commit into the public GCC source repository).

Done:- Bug 47880.

Thanks,
- Brian

Re: Using local storage pools...

[Randy Brukardt]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:7elam6trrv39c3p9iop4fiduqa1jrat4r4@4ax.com...
>I am trying to learn a little about storage pools, with a view to 
>(hopefully)
> using local pools to improve the Binary_Trees benchmark in the same way as 
> some
> of the faster C benchmarks.
>
> Arguably they cheat : they do not explicitly free each tree node (the 
> "free"
> call has been deleted!) but free the entire pool at the end of the loop.
> But if that's valid, Ada should be able to do the same.

This sounds like a job for Ada 2012 subpools. Of course, to use them, you 
have to have an Ada 2012 compiler (and I don't think there is an 
implementation at the moment - we [the ARG] just approved the AI last week).

If the pools are completely disjoint and you can live with local access 
types, you can use individual local pool objects to do the job, but that 
typically isn't the case in practice.

You can write a pool to do mass deallocations, but such a pool is always 
erroneous according to the language (both Ada 95 and Ada 2005), so there can 
be no guarentee that it will work on another compiler. [Bob Duff will tell 
you that the intent was such things would work, and they often will - as 
compilers don't try to do bad things unless there is a good reason - but the 
language doesn't provide any help.]

                                                Randy. 

Re: Using local storage pools...

[Randy Brukardt]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:7elam6trrv39c3p9iop4fiduqa1jrat4r4@4ax.com...
>I am trying to learn a little about storage pools, with a view to 
>(hopefully)
> using local pools to improve the Binary_Trees benchmark in the same way as 
> some
> of the faster C benchmarks.
>
> Arguably they cheat : they do not explicitly free each tree node (the 
> "free"
> call has been deleted!) but free the entire pool at the end of the loop.
> But if that's valid, Ada should be able to do the same.

Another thought: the Multiway_Tree container may very well have this 
behavior. The bounded version *has* to have this behavior. Not sure what 
effect using the container would have on the benchmark, but it would be an 
interesting option to try. (Of course, this is another Ada 2012 feature, but 
it is easy to implement in existing compilers and I believe it is available 
in recent versions of GNAT.)

                                       Randy.

Re: Using local storage pools...

[anon]

In <7elam6trrv39c3p9iop4fiduqa1jrat4r4@4ax.com>, Brian Drummond <brian_drummond@btconnect.com> writes:
>I am trying to learn a little about storage pools, with a view to (hopefully)
>using local pools to improve the Binary_Trees benchmark in the same way as some
>of the faster C benchmarks.
>
>Arguably they cheat : they do not explicitly free each tree node (the "free"
>call has been deleted!) but free the entire pool at the end of the loop.
>But if that's valid, Ada should be able to do the same.
>
>http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html
>suggests System.Pool_Local offers a way to do likewise - a pool that is
>automatically reclaimed when it goes out of scope.
>


Every language has it pluses and minuses, this includes both C and Ada. As 
for storage pools there are reasons to have a global and others to use local 
routines. Just because C has local pools is no reason for Ada to have this 
type of pool. And as for using reasons stated by GNU which GNAT uses as it 
backend may not be valid for Ada.  Plus, GNAT in converting Ada to the 
GNU C/C++ internal language, GNAT loses some of it elegant of Ada.

So, Ada 2012 may have some local pools, based on the C code design that is 
"wrong for Ada", which may cause more harm than any additional to the use 
of Ada.

If you want local pools then design and create your own package routines for
your application instead of complaining that Ada should have it because 
C/C++ has it. And it could be a good tools for learning both Ada and the 
usage of storage pools. That way you can adjust the package to your needs 
instead of having to re-write your code to fit within the newly design 
ARG packages. Plus if your design is better than C or the ARG package you 
could even submit it the ARG and it might be an alternative or replacement 
for the initial ARG local storage pool package.

Re: Using local storage pools...

[Pascal Obry]

Le 26/02/2011 09:41, anon@att.net a écrit :
> Every language has it pluses and minuses, this includes both C and Ada. As
> for storage pools there are reasons to have a global and others to use local
> routines. Just because C has local pools is no reason for Ada to have this
> type of pool. And as for using reasons stated by GNU which GNAT uses as it
> backend may not be valid for Ada.  Plus, GNAT in converting Ada to the
> GNU C/C++ internal language, GNAT loses some of it elegant of Ada.

This is just misconception. GNAT does not convert to GNU C/C++ whatever. 
It converts to the GNU compiler collection internal representation has 
done with C, C++, and other front-end languages. In other terms it 
shares the same back-end which is enhanced regularly to better support 
all languages.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Using local storage pools...

[Ludovic Brenta]

anon@att.net writes:
> Brian Drummond writes:
>> I am trying to learn a little about storage pools, with a view to
>> (hopefully) using local pools to improve the Binary_Trees benchmark
>> in the same way as some of the faster C benchmarks.
>>
>> Arguably they cheat : they do not explicitly free each tree node (the
>> "free" call has been deleted!) but free the entire pool at the end of
>> the loop.  But if that's valid, Ada should be able to do the same.
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html
>> suggests System.Pool_Local offers a way to do likewise - a pool that
>> is automatically reclaimed when it goes out of scope.
>
> Every language has it pluses and minuses, this includes both C and
> Ada. As for storage pools there are reasons to have a global and
> others to use local routines. Just because C has local pools is no
> reason for Ada to have this type of pool.

C does not have local pools; these are provided by the external Apache
Portable Run-time Library which is not part of the language.  Similarly,
the C++ version uses the pools from the Boost library, which is not part
of the language either.

> And as for using reasons stated by GNU which GNAT uses as it backend
> may not be valid for Ada.  Plus, GNAT in converting Ada to the GNU
> C/C++ internal language, GNAT loses some of it elegant of Ada.

No, it doesn't, because the internal representation used by GCC is
called GIMPLE, looks like LISP, is not specific to any one language, and
can represent all of Ada's elegance.

> So, Ada 2012 may have some local pools, based on the C code design
> that is "wrong for Ada", which may cause more harm than any additional
> to the use of Ada.

Are you assuming that Randy and the other members of the ARG are idiots
who blindly repeat mistakes from other languages?  If that were the
case, Ada would not be Ada.

> If you want local pools then design and create your own package
> routines for your application instead of complaining that Ada should
> have it because C/C++ has it.

But Ada has pools *in the language* whereas C and C++ must rely on
third-party libraries.  And GNAT, specifically, provides local pools for
just that purpose.  And where did you get the notion that Brian was
complaining about anything?

> And it could be a good tools for learning both Ada and the usage of
> storage pools. That way you can adjust the package to your needs
> instead of having to re-write your code to fit within the newly design
> ARG packages. Plus if your design is better than C or the ARG package
> you could even submit it the ARG and it might be an alternative or
> replacement for the initial ARG local storage pool package.

Brian says he is trying to "learn a little about storage pools."  Do you
really think he can do a better job at designing storage pools than the
ARG with their cumulated decades of experience?

-- 
Ludovic Brenta.

Re: Using local storage pools...

[Pascal Obry]

Le 26/02/2011 04:02, Randy Brukardt a écrit :
> This sounds like a job for Ada 2012 subpools. Of course, to use them, you
> have to have an Ada 2012 compiler (and I don't think there is an
> implementation at the moment - we [the ARG] just approved the AI last week).

Hum, can you tell me more about this AI? What's the number?

Thanks,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Using local storage pools...

[Pascal Obry]

Le 26/02/2011 19:41, Pascal Obry a écrit :
> Le 26/02/2011 04:02, Randy Brukardt a écrit :
>> This sounds like a job for Ada 2012 subpools. Of course, to use them, you
>> have to have an Ada 2012 compiler (and I don't think there is an
>> implementation at the moment - we [the ARG] just approved the AI last
>> week).
>
> Hum, can you tell me more about this AI? What's the number?

I think I found it:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0111-3.txt?rev=1.8

reading now...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Using local storage pools...

[anon]

In <87mxljuio1.fsf@ludovic-brenta.org>, Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>anon@att.net writes:
>> Brian Drummond writes:
>>> I am trying to learn a little about storage pools, with a view to
>>> (hopefully) using local pools to improve the Binary_Trees benchmark
>>> in the same way as some of the faster C benchmarks.
>>>
>>> Arguably they cheat : they do not explicitly free each tree node (the
>>> "free" call has been deleted!) but free the entire pool at the end of
>>> the loop.  But if that's valid, Ada should be able to do the same.
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gnat_ugn_unw/Some-Useful-Memory-Pools.html
>>> suggests System.Pool_Local offers a way to do likewise - a pool that
>>> is automatically reclaimed when it goes out of scope.
>>
>> Every language has it pluses and minuses, this includes both C and
>> Ada. As for storage pools there are reasons to have a global and
>> others to use local routines. Just because C has local pools is no
>> reason for Ada to have this type of pool.
>
>C does not have local pools; these are provided by the external Apache
>Portable Run-time Library which is not part of the language.  Similarly,
>the C++ version uses the pools from the Boost library, which is not part
>of the language either.
>
>> And as for using reasons stated by GNU which GNAT uses as it backend
>> may not be valid for Ada.  Plus, GNAT in converting Ada to the GNU
>> C/C++ internal language, GNAT loses some of it elegant of Ada.
>
>No, it doesn't, because the internal representation used by GCC is
>called GIMPLE, looks like LISP, is not specific to any one language, and
>can represent all of Ada's elegance.
>
>> So, Ada 2012 may have some local pools, based on the C code design
>> that is "wrong for Ada", which may cause more harm than any additional
>> to the use of Ada.
>
>Are you assuming that Randy and the other members of the ARG are idiots
>who blindly repeat mistakes from other languages?  If that were the
>case, Ada would not be Ada.
>
>> If you want local pools then design and create your own package
>> routines for your application instead of complaining that Ada should
>> have it because C/C++ has it.
>
>But Ada has pools *in the language* whereas C and C++ must rely on
>third-party libraries.  And GNAT, specifically, provides local pools for
>just that purpose.  And where did you get the notion that Brian was
>complaining about anything?
>
>> And it could be a good tools for learning both Ada and the usage of
>> storage pools. That way you can adjust the package to your needs
>> instead of having to re-write your code to fit within the newly design
>> ARG packages. Plus if your design is better than C or the ARG package
>> you could even submit it the ARG and it might be an alternative or
>> replacement for the initial ARG local storage pool package.
>
>Brian says he is trying to "learn a little about storage pools."  Do you
>really think he can do a better job at designing storage pools than the
>ARG with their cumulated decades of experience?
>
>-- 
>Ludovic Brenta.


From Adacore : http://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm

  1.2 The GNAT Compiler
  ...
  "In order to bridge the semantic gap between Ada and C, several GCC code 
   generation routines have been extended, and others added, so that the 
   burden of translation is also assumed by GIGI and GCC whenever it is 
   awkward or inefficient to perform the expansion in the front-end. For 
   example, there are code generation actions for exceptions, variant parts 
   and accesses to unconstrained types. As a matter of GCC policy, the code 
   generator is extended only when the extension is likely to be of benefit 
   to more than one language."

The first sentence suggest the conversion is from Ada to C. And extending 
the last sentence you get that: since a some of the features of Ada like 
"Task"s to name one, are not beneficial to C or any other language the GCC 
backend is less likey to be modified to produce true optimized Ada code. 
Which means that GNAT front_end has to modify the "Task" code to some 
specific design that may not be optimized to Ada specifications.


And Wrong about LISP like! 

Using:

http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gccint/GIMPLE-Example.html#GIMPLE-Example

as an example the GIMPLE translation of the C code. The result just looks 
like an expanded or a low-level version of the C routine.  GNU Ada 
Translator (GNAT) translates Ada into C. because anything that looks like 
C, act like C, is C, no matter what you call it. So, Generic or it low-level 
off-spring Gimple is just another modified version of C!

Plus, the problem with any intermediate representation languages like 
GENERIC and GIMPLE is that they work great on the main development system 
and language (like C/C++ for GNU) and they do fair on most others languages 
with a limited few being lousy. And there is no "intermediate representation 
language" that can be optimized or include all aspects for all other 
languages. 

An example of that is concept that PL/1 (where the best features of Algol, 
Cobol, and Fortran are combine into a single language) could be used as 
"intermediate representation language". But no Algol, Cobol or Fortran 
compiler would ever consider convert their language to PL/1, just to be 
recompiled into the target system code.

Re: Using local storage pools...

[Pascal Obry]

Le 27/02/2011 05:16, anon@att.net a écrit :
>    1.2 The GNAT Compiler
>    ...
>    "In order to bridge the semantic gap between Ada and C, several GCC code
>     generation routines have been extended, and others added, so that the
>     burden of translation is also assumed by GIGI and GCC whenever it is
>     awkward or inefficient to perform the expansion in the front-end. For
>     example, there are code generation actions for exceptions, variant parts
>     and accesses to unconstrained types. As a matter of GCC policy, the code
>     generator is extended only when the extension is likely to be of benefit
>     to more than one language."
>
> The first sentence suggest the conversion is from Ada to C. And extending

Wrong again. GCC is GNU Compiler Collection it is not a C compiler. So 
GCC code generation means just that, the middle-end and backend of GCC 
(shared with the C, C++ frontends and others) has been extended.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Using local storage pools...

[Georg Bauhaus]

On 2/27/11 9:18 AM, Pascal Obry wrote:
> Le 27/02/2011 05:16, anon@att.net a écrit :
>> 1.2 The GNAT Compiler
>> ...
>> "In order to bridge the semantic gap between Ada and C, several GCC code
>> generation routines have been extended, and others added, so that the
>> burden of translation is also assumed by GIGI and GCC whenever it is
>> awkward or inefficient to perform the expansion in the front-end. For
>> example, there are code generation actions for exceptions, variant parts
>> and accesses to unconstrained types. As a matter of GCC policy, the code
>> generator is extended only when the extension is likely to be of benefit
>> to more than one language."
>>
>> The first sentence suggest the conversion is from Ada to C. And extending
>
> Wrong again. GCC is GNU Compiler Collection it is not a C compiler. So GCC code generation means just that, the middle-end and backend of GCC (shared with the C, C++ frontends and others) has been extended.
>
> Pascal.

I understand one claim is that GCC's infrastructure
had originally been made with sequential {}-languages in mind?
So that GCC's infrastructure won't be best for a concurrent language
such as Ada.
Consequently, that GNAT might actually profit from any changes
to GCC infrastructure in case they'll change it in order to support
the new C++ with its concurrency libraries.

Is it true at all that GCC's internals are biased towards "sequential"?
Hasn't even the C part grown with POSIX threads and corresponding
needs?  Grown with GCC being used as the system compiler of a major
commercial server operating system (GNU/Linux) written in C and
being a multitasking OS?

Is it true at all that GCC's infrastructure is unaware of parallelism?
GCC supports many of the primitive "concurrency instructions"
like read-and-increment or test-and-set.  So I don't think it is
true that today's GCC infrastructure neglects concurrency.

Is it likely that Apple could have developed Grand Central
Dispatch for the Objective-C part of GCC if using its backend
had been in the way ofthe concurrency goal?
They are switching to LLVM and CLang, though.

Curiously, the parallelism built-ins are readily available
to languages such as C and, to a lesser extent, to Ada.
Fortunately, recent GNAT makes some of these available, like the
SIMD instructions  for processors made by AMD and Intel.