[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: better malloc strategies



Howard Chu wrote:
And another oops. The single-thread numbers for glibc in this post were mis-copied (note they're identical to hoard's numbers). The multi-thread numbers and the CPU times are all correct.

The actual single-thread stats for glibc in that test run were:

Still no idea why there are such erratic jumps in its behavior.

Found the explanation for this http://sourceware.org/ml/libc-alpha/2006-03/msg00033.html

Running the glibc test with MALLOC_MMAP_THRESHOLD_ env var set to 8MB drastically improved its performance. Aside from some high startup overhead, it's very nearly the fastest in single-threaded, which is more in line with what other folks have written about it. Still the slowest for multi-threaded though.

       glibc            hoard            umem             tmalloc
       size  time       size  time       size  time       size  time
start   649              655              653              660	
single 1278  01:01.95   1708  00:20.23   1693  00:22.33   1353  00:20.91
single 1278  00:26.69   1747  00:11.73   1731  00:12.37   1374  00:12.26
single 1389  00:11.33   1747  00:11.09   1736  00:11.75   1374  00:11.58
single 1412  00:11.12   1748  00:11.06   1736  00:11.71   1374  00:11.58
single 1412  00:11.09   1748  00:11.05   1736  00:11.62   1374  00:11.57
single 1408  00:11.12   1748  00:11.07   1736  00:11.65   1374  00:11.58
single 1412  00:11.11   1748  00:11.06   1736  00:11.54   1374  00:11.56
single 1402  00:11.11   1748  00:11.07   1736  00:11.51   1374  00:11.52
four   1504  00:27.48   1801  00:19.37   1786  00:19.44   1435  00:19.64
four   1502  00:24.24   1801  00:19.22   1799  00:20.90   1451  00:20.44
four   1501  00:23.67   1829  00:19.18   1807  00:19.41   1451  00:19.89
four   1497  00:23.47   1832  00:21.12   1821  00:19.84   1451  00:19.92
four   1498  00:23.68   1832  00:19.50   1821  00:21.27   1451  00:19.91
four   1498  00:23.71   1832  00:19.35   1821  00:19.63   1451  00:19.97
four   1512  00:23.71   1832  00:19.40   1821  00:19.36   1451  00:19.88
four   1512  00:24.53   1832  00:19.51   1821  00:19.59   1451  00:19.98
CPU1         02:36.32         01:38.54         01:45.14         01:42.62
CPU final    06:36.88         05:01.90         05:11.78         05:02.91

This is with current back-bdb (HEAD as of yesterday), slightly faster overall than the January 1 code. It still looks like a tradeoff between hoard for best speed bs tcmalloc for best memory efficiency.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/