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 :(
