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

[Tim Janik <timj imendio com>]

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
> place.
>
> > 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?

> Soren

---
ciaoTJ