Re: GSlice x GNU Libc malloc benchmark

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

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
not surprisingly, it looks no different then the image produced while
using the default threshold.


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.


Attachment: slice.png
Description: slice.png

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]