On 12/16/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 15.12.2006, at 19:59, Vlad Seryakov wrote: >> >> http://www.nedprod.com/programs/portable/nedmalloc/index.html Hm... not bad at all: This was under Solaris 2.8 on a Sun Blade2500 (Sparc) 1GB memory: Testing standard allocator with 8 threads ... This allocator achieves 2098770.683107ops/sec under 8 threads Testing nedmalloc with 8 threads ... This allocator achieves 1974570.587561ops/sec under 8 threads Testing Tcl alloc with 8 threads ... This allocator achieves 1449969.176647ops/sec under 8 threads Now on a SuSE Linux, a 1.8GHz Intel: Testing standard allocator with 8 threads ... This allocator achieves 1752893.072620ops/sec under 8 threads Testing nedmalloc with 8 threads ... This allocator achieves 2114564.246869ops/sec under 8 threads Testing Tcl alloc with 8 threads ... This allocator achieves 1460851.824732ops/sec under 8 threads The Tcl library was compiled for threads and uses the zippy allocator. This is how I compiled the test program from the nedmalloc package: gcc -O -g -o test test.c -lpthread -DNDEBUG -DTCL_THREADS -I/usr/ local/include -L/usr/local/lib -ltcl8.4g I had to make some tweaks as they have a problem in pthread_islocked() private call. Also, I expanded the testsuite to include Tcl_Alloc/ Tcl_Free in addition. If I run this same thing on other platforms I get more/less same results with one notable exception: o. nedmalloc is always faster then standard or zippy, except on Sun Sparc where the built-in malloc is the fastest o. zippy (Tcl) allocator is always the slowest among the three Now, I imagine, the nedmalloc test program may not be telling all the truth (i.e. may be biased towards nedmalloc)... It would be interesting to see some other metrics...
Some other metrics: http://archive.netbsd.se/?ml=OpenLDAP-devel&a=2006-07&t=2172728 The seem, in the end, to go for Google tcmalloc. It wasn't the absolute fastest for their particular set of tests, but had dramatically lower memory usage. Something to think about: does the nedmalloc test include allocating memory in one thread and freeing it in another? Apparently this is tough for some allocators, such as Linux ptmalloc. Naviserver does this.
