Re: Using local storage pools...

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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