Re: GSlice with tight memory (Re: Help Needed)

On Tue, 22 Aug 2006, Soeren Sandmann wrote:

Tim Janik <timj imendio com> writes:

In general, I'd recommend just always using

       g_slice_set_config (G_SLICE_CONFIG_ALWAYS_MALLOC, 1);

This way the various tools, valgrind and memprof, will work with your
application, and you don't get any surprises with pathological cases
causing run-away caching. The speed difference between g_slice and
g_malloc is basically noise as soon as you include the time to
initialize the new block of memory.

in general? that is certainly bogus, if what you said was true, there'd
be no point in having GSlice in the first place.

I don't think there was any point in having GSlice in the first

do you have any benchmark (data) that backs up your claims?

Just add initialization of the memory to glib/tests/slice-test.c, and
any real speed difference vanishes. I don't have the patch anymore.

Even without initialization, there is just not that much of a
difference. On my laptop I just got:

GSlice, one thread:             0.23.01 elapsed
malloc, one thread:             0.23.11 elapsed
GSlice, four threads:           1.32.71 elapsed
malloc, four threads:           1.31.62 elapsed

For slice-color, which does touch the allocated memory, I get:

GSlice, color incr 1:         14.47s
GSlice, color incr 3:         13.84s
malloc:                       14.01s
malloc, run 2:                13.92s

None of this indicates that any of the two allocators is faster than
the other. Most importantly, there is no indication that it matters in
the real world.

that just shows that your laptop and *newer* glibc is fast enough for
the allocation algorithm to not be the bottleneck with these tests.
it'd be nice if you outlined what CPU, what/how much memory and
particularly what glibc version you are using (and what block size you
tested slice-test at). since 2.3.2 gets nowhere close GSlice, e.g. on
an AMD-1833MHz, 1GB, glibc-2.3.2:

slice-test (GSlice): 0m22.564s
slice-test (Malloc): 1m48.862s

this types of test will even look vastly more different on other machines
(also processors, even Intel vs. AMD can make a huge difference here), on
other OSes, and especially other libcs (also older glibcs).

as for slice-color, that test just shows that GSlice is up on par with
malloc as far as cache colorization is concerned, which is good, because
glibc's malloc gets this right. if you want to see what difference
colorization can make, try a color increment of 0.

Except for higher i-cache load and bugs complaining about pathological
caching with GSlice, that is.

i haven't seen such a bug report yet, can you post a URL please?



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