Benchmarks:

http://fortranland.com/compare_7.9_block_alloc.txt

This is a diff between 177 runs of pike -x benchmark from the 7.9 branch and the same 177 runs with arne/block_alloc. Brackets give precision, +/- shows deviation within the runs.

best,

tobi

"Tobias S. Josefowitz" t.josefowitz@gmail.com 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 el@laramies.com 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.