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
On 16.12.2006, at 15:00, Zoran Vasiljevic 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 on a iMac with Intel Dual Core 1.83 Ghz and 512 MB memory
Testing standard allocator with 8
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
On 12/16/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
Hey! I think our customers will love it! I will now try to
ditch the zippy and replace it with nedmalloc... Too bad that
Tcl as-is does not allow easy snap-in of alternate memory allocators.
I think this should be lobbied for.
It would
On 16.12.2006, at 16:25, Stephen Deasey wrote:
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.
The down side of tcmalloc: only Linux port.
The nedmalloc does them all (win, solaris,
On 15.12.2006, at 19:59, Vlad Seryakov wrote:
Will try this one.
To aid you (and others):
http://www.archiware.com/downloads/nedmalloc_tcl.tar.gz
Download and peek at README file. This compiles on all
machines I tested and works pretty fine in terms of speed.
I haven't tested the
On 12/16/06, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
Are you sure? AFAIK, we just go down to Tcl_Alloc in Tcl library.
The allocator there will not allow you that. There were some discussions
on comp.lang.tcl about it (Jeff Hobbs knows better). As they (Tcl)
just inherited what aolserver had
On 16.12.2006, at 17:15, Stephen Deasey wrote:
Yeah, pretty sure. You can only use Tcl objects within a single
interp, which is restricted to a single thread, but general
ns_malloc'd memory chunks can be passed around between threads. It
would suck pretty hard if that wasn't the case.
Instead of using threadspeed or other simple malloc/free test, i used
naviserver and Tcl pages as test for allocators.
Using ab from apache and stresstest it for thousand requests i test
several allocators. And
having everything the same except LD_PRELOAD the difference seems pretty
clear.
You can, it moves Tcl_Objs struct between thread and shared pools, same
goes with other memory blocks.On thread exit
all memory goes to shared pool.
Zoran Vasiljevic wrote:
On 16.12.2006, at 17:15, Stephen Deasey wrote:
Yeah, pretty sure. You can only use Tcl objects within a single
On 16.12.2006, at 17:29, Vlad Seryakov wrote:
Instead of using threadspeed or other simple malloc/free test, i used
naviserver and Tcl pages as test for allocators.
Using ab from apache and stresstest it for thousand requests i test
several allocators. And
having everything the same except
On 16.12.2006, at 16:25, Stephen Deasey wrote:
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.
I'm still not 100% ready reading
But if speed is not important to you, you can supply Tcl without zippy,
then no bloat, system is returned with reasonable speed, at least on
Linux, ptmalloc is not that bad
Zoran Vasiljevic wrote:
On 16.12.2006, at 16:25, Stephen Deasey wrote:
Something to think about: does the nedmalloc
On 16.12.2006, at 19:31, Vlad Seryakov wrote:
But if speed is not important to you, you can supply Tcl without
zippy,
then no bloat, system is returned with reasonable speed, at least on
Linux, ptmalloc is not that bad
Eh... Vlad...
On the Mac the nedmalloc outperforms the standard
On 16.12.2006, at 19:31, Vlad Seryakov wrote:
Linux, ptmalloc is not that bad
Interestingly. ptmalloc3 (http://www.malloc.de/) and
nedmalloc both diverge from dlmalloc (http://gee.cs.oswego.edu/malloc.h)
library from Doug lea. Consequently, their performance
is similar (nedmalloc being
15 matches
Mail list logo
