On Fri, 5 May 2006, Fabrício Barros Cabral wrote:
Hello all! Motivated by the incredibles results of GSlice X GNU Libc malloc memory allocators, I decided do a small benchmark between these memory allocators. My idea is very simple: I'll running both allocators, increasing the number of bytes of memory allocated, several times, and sum the all total time.
note that this isn't neccessarily a good benchmark to measure allocator performance. e.g. gslice is tuned to perform well in multithreaded scenarios, and to be quick for frequent *reallocations* of memory. simply because that reflects to a great extend common preasure on memory systems in modern programs. your benchmark comes nowhere near testing that kind of scenario (you're not reallocating at all). also, GSlice uses memalign() as its base allocator which may or may not affect the performance of other malloc()/free() calls when intermixed, depending on your current libc's allocator implementation.
I'm redireting the results to a plain text file, and using the gnuplot to plot a chart, for a visual comparing. My problem is when I'm allocing the segments, they aren't being freeing. Could you check where is my fault?
that's becaus the slice allocator has a timing threshold to keep recent allocations in memory. by default, this is set to 15 seconds, meaning, it won't even attempt to release newly freed memory of a certain chunk size, unless a certain amount of memory of this chunk size resides in its cache for more than 15 seconds. that's very bad for your benchmark, but works fairly well for normal applicaiton allocation behaviour ;) for test purposes, this timeout can be tweaked btw, doing so for any other purposes is *not* recommended. e.g. you could run your benchmark with: g_slice_set_config (G_SLICE_CONFIG_WORKING_SET_MSECS, 0); that'll result in *very* poor performance however, because this will eagerly empty the slice caches and thusly pass through the memory pressure to memalign()/free(). in essence you'll be benchmarking memalign() with a bit of free-list caching on top, not really GSlice behaviour though. a better choice for somewhat lengthy-running benchmarks might be: g_slice_set_config (G_SLICE_CONFIG_WORKING_SET_MSECS, 250 * 1000); but then, this is only going to be useful if you actually make *reallocations*. e.g. like glib/tests/slice-test.c does it. if you don't ever make reallocations, the logic that gives memory back to the system after the timeout threshold passed by won't ever get triggered.
In attach, I'm sending the benchmark code and the script which I use to plot the chart in gnuplot. So, you should: 1) Compile the program (trivial for you); 2) Running, using: fx-gslice-benchmark > mem.list 3) So, in gnuplot prompt> load "slice.gnu" What result in a slice.png, a nice chart of the performance of GSLice and Libc Malloc. Thanks for you attention, and sorry for my poor english! :)
you might wanna add: set term png enhanced size 1024,768 there to get a somehwat larger image. for everyone ont wanting to run the benchmark themselves, i've attached the image produced by a test run on my athlon-1833.218MHz system, using a G_SLICE_CONFIG_WORKING_SET_MSECS of 250 * 1000. not surprisingly, it looks no different then the image produced while using the default threshold.
--fx P.S. Is it the correct list for this or should I use the performance-list for this stuff?
i'm not regularly monitoring the performance-list, and you probably want to make sure to catch my attention for any gslice issues, so for this kind of benchamrks, gtk-devel-list is a good place. --- ciaoTJ
Attachment:
slice.png
Description: slice.png
