Jason Evans wrote: > On 28 November, I announced a new malloc implementation that I've been > working on as a replacement for the current libc malloc. The main goal > for this rewrite of malloc is to provide better scalability for > multi-threaded programs on SMP systems, without degrading performance > in general. The benchmarks I've run indicate that the code now meets > this goal. > ... Great! > === > === Benchmarking ad nauseam === > === > ==> sh6bench (single-threaded) >... > phkmalloc doesn't fare very well with its default settings since the > benchmark's memory usage fluctuates enough to cause phkmalloc to > repeatedly allocate and free pages. Therefore I report numbers for > multiple MALLOC_OPTIONS settings. Since the program prompts for > interactive input, I report the sum of user and sys time, rather than > wall time. (Same VMware setup as for super-smack benchmarks.) > > user+sys time (seconds) > phkmalloc 'aj': 25.66, 25.78, 22.50 > phkmalloc 'aj>>>>': 13.72, 13.77, 13.69 > jemalloc 'aj': 17.88, 17.05, 17.10 > > If phkmalloc's cache size is increased adequately, it beats jemalloc. > jemalloc simply has to do more work when splitting and coalescing > regions than phkmalloc does, and this benchmark severely stresses that > aspect of jemalloc. It's perhaps worth noting that jemalloc's peak > memory usage is ~22% lower than phkmalloc's, which means that it's > doing a better job of avoiding fragmentation. At least the extra > algorithmic overhead gains us something. > If I have linked " aj>>>>>>>" to /etc/malloc.conf for phkmalloc, the super-smack get better result, on my Pentium-D 2.8Ghz machine, before this set, the select-key.smack can only reach 19500 q_per_s, after the set, it can reach 20791.33 q_per_s ! The '>' option should be supported in jemalloc because mysql relies on it. > So, how about it? Is jemalloc ready to go in now? > > Thanks, > Jason In general, it is fine to me, I don't have other use-cases to test, others may try apache web benchmark etcs? David XuReceived on Fri Dec 23 2005 - 09:05:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:49 UTC