That could be true on Solaris, but in Linux 2.6 mmap/munmap is very fast
and looking into kernel source it tells you that they conver sbrk ito
mmap imternally but the different is that mmap is multithreaded-aware
while sbrk not.
Now, using mmap to allocate block of memory and then re-using that this
is waht i am doing, but i do not use munmap, still it is possible.
With random allocations from 1-128L, Tcl alloc gives the worst results,
constantly, which means it is good on small allocations only?
Tcl: 8.4.12, threads 16, loops 500000
starting 16 malloc threads...waiting....done: 3 seconds, 955518 usec
starting 16 ckalloc threads...waiting....done: 4 seconds, 272964 usec
starting 16 _malloc threads...waiting....done: 1 seconds, 890566 usec
I am not trying to re-invent the wheel, it is just accidentally i
replaced sbrk with mmap and removed mutexes around it and it became much
faster than what we have now, at least on Linux.
Stephen Deasey wrote:
On 2/3/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Here is the test http://www.crystalballinc.com/vlad/tmp/memtest.c
It give very strange results, it works for Linux only because it uses
mmap only and it looks like brk uses mmap internally according to Linux
2.6.13 kernel and it allows unlimited mmap-ed regions (or as i
understand up to vm.max_map_count = 65536).
According to this test, when i use random sizes from 0-128k, Tcl
allocator gives worse results than Linux malloc. On small amounts
ckalloc faster but once over 64k, Linux malloc is faster. And, my small
malloc implementaion which is based on first version of Lea's malloc and
uses mmap only and supports per-thread memory only beats all mallocs,
especially on bigger sizes. It does not crash, even on 5Mil loops, but i
am not sure why it is so simple and so effective.
Have you taken fragmentation into account?
There's some memory related links in this blog post I read recently:
http://primates.ximian.com/~federico/news-2005-12.html#14
Federico makes a good point: this has all been done before...
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________
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/
