"Tobias S. Josefowitz" <[email protected]> wrote: >> I guess you already told us at the conference, but what was your >> motivation for creating it? > > The linear lookup in the existing one...
Just to make it clear, you're talking about the linear lookup to find the right block when structs are freed? >> Is std::allocator the same thing as the (g)libc malloc in your graphs? > > No, std::allocator is a block allocator used by std::list, std::map > and so on. Compared to glibc free/malloc, the std::allocator is quite > fast. It would be interesting to see a comparison with plain old (glibc) malloc, just to put it into perspective. >> Does it add any features? > > Slight ones. For the CritBits, we need the allocator in the object > storage (block allocators are used tree-locally). So the nodes for each critbit tree are allocated within its own blocks? Sifting through the code just briefly I got the impression the nodes were allocated from a single global pool, considering that CB_NODE_ALLOC() doesn't take any context. Did I miss something? > http://fortranland.com/compare_7.9_block_alloc.txt > http://fortranland.com/compare_7.9_block_alloc_cleanup_on_exit.txt Hmm, do you have any theories to explain the variations seen in those two? Otherwise it seems to me like there's still a lot of noise, and I suspect none of those tests really stress BLOCK_ALLOC in the way where your implementation would show its strength, i.e. freeing structs when there's a large number allocated. I figured I could add a test for that, but I can't compile CritBit from clean source on the arne/block_alloc branch: #### Making dynamic: post_modules/CritBit make[5]: *** No rule to make target `/home/mast/Pike/devel/src/post_modules/CritBit/bitvector.h', needed by `inttree.o'. Stop. make[4]: *** [all] Error 2 make[3]: *** [CritBit] Error 1 And of course, a couple of CritBit benchmarks would be welcome - they also ought to show off GJAlloc, right? ;) Arne Goedeke <[email protected]> wrote: >> Does it add any features? > Well, yes. Actually, there is one thing. Since its not all macros it > would be possible to have several ones around just for one task and free > everything in one go at the end. Something similar to what the gc is > doing right now, although there its only one gc at a time, anyway ,) Right. > And then, it might be even handier to have one which never frees, except > right at the end when all pages are discarded. Possibly, but the old one is quite good at that detail already, isn't it? Btw, I pushed a few small fixes to be able to compile with GJAlloc in rtldebug mode (when you're developing C modules, I really recommend that mode, btw). I'm not that happy with the condition I put into BLOCK_ALLOC_IN_USE, though. I thought block_allocator.pages would be better, but that doesn't work with BA_USE_MEMALIGN. I hope you can come up with something better.
