李鑫 (LI Xin) wrote:
在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道：
On -CURENT amd64 (Athlon64 3000+, 512k L2 cache):
With jemalloc (without MY_MALLOS):
~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000
...
116.34 real 113.69 user 0.00 sys
With MY_MALLOC:
~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000
...
45.30 real 44.29 user 0.00 sys
Have you turned off the debugging options, i.e. ln -sf
'aj' /etc/malloc.conf?
If you want to do a fair comparison, you will also define
NO_MALLOC_EXTRAS when compiling malloc.c, in order to turn off the
copious assertions, not to mention the statistics gathering code.
Before you do that though, it would be useful to turn statistics
reporting on (add MALLOC_OPTIONS=P to your environment when running the
test program) and see what malloc says is going on.
[I am away from my -current system at the moment, so can't benchmark the
program.] If I understand the code correctly (and assuming the command
line parameters specified), it starts out by requesting 3517 2000-byte
allocations from malloc, and never frees any of those allocations.
Both phkmalloc and jemalloc will fit two allocations in each page of
memory. phkmalloc will call sbrk() at least 1759 times. jemalloc will
call sbrk() approximately 6 times. 2kB allocations are a worst case for
some of jemalloc's internal bookkeeping, but this shouldn't be a serious
problem. Fragmentation for these 2000-byte allocations should total
approximately 6%.
malloc certainly incurs more overhead than a specialized sbrk()-based
allocator, but I don't see any particular reason that jemalloc should
perform suboptimally, as compared to any complete malloc implementation,
for fdtd. If you find otherwise, please tell me so that I can look into
the issue.
Thanks,
Jason
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
