benchmark on binary trees

[visitor via Digitalmars-d-learn]

On Monday, 7 December 2015 at 10:55:25 UTC, Alex wrote:
> On Sunday, 6 December 2015 at 12:23:52 UTC, visitor wrote:
>> Hello, interesting exercise for me to learn about allocators 
>> :-)
> Nice to know, a novice can inspire someone :)
>
>> i managed to parallelize the code reaching similar 
>> performance, in terms of speed, as the non parallel version :
>> http://dpaste.dzfl.pl/6c3e6edcff59
> Cool! This is what I looked for!
>
>> BUT it consumes insane memory, don't try with argument more 
>> than 17 !!!
>>
> I assume, the allocator itself is something, that is not really 
> needed in this case. Maybe, there is a more straight forward 
> access to the problem. Even a simpler then in all the versions 
> on the benchgame site, but I don't see it right now.
> And with the allocator attempt I had a chance to experiment 
> with the experimental module and to write a very quick copy of 
> a program, which I want to have...

i've got more speed improvement with "taskPool.parallel(depthind, 
2)" in the foreach parallel loop : second argument are workUnits 
(2 for me, on a quad core gave best results)
Also using directly "FreeList!(Mallocator, Tree_node.sizeof)" 
without wrapping it in an allocatorObject gives speed improvement 
(with changes to makeTree method)

i took inspiration from the C code, they use a memory pool 
management, like anonymous already pointed in c++ version, which 
i think could (must?) be achieved with allocators, to gain speed 
i think it's a key point, no GC !! FreeList allocator appears (to 
me) as a good candidate for this.

but as i'm new to this, i'm sure to not doing it the right way !

i tried the exact same FreeList allocator but backed with the 
GCAllocator (not the Mallocator used in my code), then memory 
consumption is very good but of course it"s slow !

i tried a lot of other allocators, variations on the presented 
code, but memory management is awful :(