Right, the speed we have with zippy and this is the absolute winner in
this category. All that started because of memory bloat and zippy here
is the absolute loser. As for Tcl/Naviserver environment in which we
work we need to find balance between lock contention and memory bloat.
Even on Linux regular malloc behaves not that fast when used under
Tcl/Naviserver, pure memory/pthread benchmark does not reveal that.
Try to run different mallocs under naviserver for a while, even with ab
tool and some simple Tcl test page, you will notice the difference in
speed and memory usage.
For us, vmalloc already proved to be useful, we have busy server with
only 1Gb of memory with lots of threads and aggressive caching, vmalloc
reduced memory/swap usage by 700Mb, now with configured connsperthread
and jobsperthread with reasonable limits, memory will be returned to the
system on regular basis without significant drop in speed. Actually,
with zippy it was running slower because of too much swaping involved
after some time, so initial speed and long lasting speed happened to be
not the same.
Not that i am convincing that vmalloc is better than others, it is
specialized to be used in Tcl alone or with Naviserver, it is not
general purpose but still can be used this way if needed. Just wanted
others to test and see how it works, i only tested it on Linux.
Under Linux it should be used with mmap enabled, this way it is fast and
memory is returned directly to the system, on other systems it looks
like mmap causes problems, so using malloc makes it slower on Solaris
where standard malloc is fast enough.
Another nice thing, you do not need to recompile Tcl, it can be built
with zippy, and then just LD_PRELOAD or can be compiled into the main
program on OSX directly and its functions will be used instead of
later-linked Tcl ones.
Still, good to know how it works on different OSes, Thanks
Zoran Vasiljevic wrote:
On 22.12.2006, at 15:59, Vlad Seryakov wrote:
Try malloctest, tclalloctest is not real test, it just calls
TclThreadAllocObj to see how fast is local linked list, really does
not test
On Solaris:
-bash-3.00$ ./malloctest
malloc: threads 4, loops 50000, buffer 16384: 0 seconds, 86483 usec
-bash-3.00$ ./vmalloctest
vmalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 86929 usec
-bash-3.00$ ./ckalloctest
ckalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 81667 usec
On Mac:
iMac1:~/vmalloc zoran$ ./malloctest
malloc: threads 4, loops 50000, buffer 16384: 0 seconds, 519085 usec
iMac1:~/vmalloc zoran$ ./vmalloctest
vmalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 369680 usec
iMac1:~/vmalloc zoran$ ./ckalloctest
ckalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 377635 usec
A SuSE 9.2 Linux on a AMD Athlon XP 2200+
[EMAIL PROTECTED]:~/vmalloc> ./malloctest
malloc: threads 4, loops 50000, buffer 16384: 0 seconds, 61715 usec
[EMAIL PROTECTED]:~/vmalloc> ./vmalloctest
vmalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 77526 usec
[EMAIL PROTECTED]:~/vmalloc> ./ckalloctest
ckalloc: threads 4, loops 50000, buffer 16384: 0 seconds, 68874 usec
This proves what I've found already: Mac OSX malloc is slow.
Solaris and Linux standard malloc are fast enough.
Generally, on modern Solaris or Linux, you need not fiddle with any
external malloc routine. The built-in malloc is optimal in terms of
speed and memory usage.
The other extreme is Mac OSX. There you need some kind of external
malloc handling.
I guess, after all this endeavours, that it is really not that important
to cook up your own malloc routine nowdays. Standard OS tools are fully
acceptable (with a Mac OSX being a notable exception).
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
