On Thu, 13 Jun 2013, Per Hedbor () @ Pike (-) developers forum wrote:
Yes, I see. I will merge the new block alloc and keep the new pike_frame code. I have probably not read it properly, then.
... current 7.9 doesnt work for me, right now.
It does not work with DEBUG enabled currently, I will commit a fix for that shortly.
If you have some other issue (say, related to files->_Stdio) do
git clean -f # (NOTE: Will delete uncommited files) rm -fr src/modules/files rm -fr build (cd src;./run_autoconfig) make MAKE_PARALLEL='-j5'
My problem was that some modules were not being recompiled after the type renumbering. And of course this lead to all kinds of weird errors.
I tried to benchmark
Just some numbers from my runs:
Before any of the recent fixes: 7.8: Binary Trees............... 320211/s (160Mb) 7.9.5: Binary Trees............... 409130/s (134Mb) yesterday: Binary Trees............... 508800/s (132Mb)
The difference was much bigger if binary tree:s test with less deep but more trees, this time is dominated by really_free_object and gc.
.. which brings us to ..
today: Binary Trees............... 936518/s (43Mb) (3x faster than 7.8!)
Not bad. :)
Any idea why it's only using about 30% of the RAM? :)
Hm, that seems like a mismeasurement. The shootout always measured ram usage after the benchmark has been run. Depending on when memory is actually deallocated, it might show very different numbers. If I modify the BinaryTree test and read statm or use _memory_usage() during the test, there is no big difference between versions. Without investigating it, I guess that one reason why memory can be freed much more easily is, that the new block allocator will double page sizes whenever a new page is needed. It will therefore very quickly start using mmap instead of sbrk. Of course, if all blocks are freed, the mapped page can be actually reclaimed much more easily; lowering sbrk is often not possible.
arne