Re: GIO will link with -pthread soon

2009/11/12 Owen Taylor <otaylor redhat com>:
> On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote:
>> On Wed, 2009-11-11 at 23:10 -0500, Ryan Lortie wrote:
>> > The easiest fix here is to link libgio with -pthread.  We discussed this
>> > at the GTK meeting yesterday and decided to do this unless anyone on the
>> > list has a compelling reason not to.
>> Its certainly an easy fix. However, it will inflict e.g. threadsafe
>> malloc and all the other libc functions on all single-threaded Gtk+ apps
>> which is not a small cost (although the Gtk+/glib locking will not be
>> enabled unless you call g_thread_init()).
> Do we have the numbers for that? The original gthread split was done
> based on timings I did in 1999 or so, and if I recall, showed an overall
> overhead of 5% or so for allocation intensive GTK+ code (like
> constructing a large tree of widgets.)
> 10 years later we have GSlice, a completely different implementation of
> threads, and very different processors so it's very hard to extrapolate
> from those original measurements.

As a quick'n'silly test to get a feel of the difference I did a run of
alloc/free benchmark, just doing g_new()&g_free() for 1000 units of
the GList struct in a sufficently long loop to spend ~22s doing it.

The result? The version with g_thread_init() and built with
gthread-2.0 averaged in around 22.00s and the "single threaded"
averaged at around 22.6s. Just adding gthread-2.0 to the build but not
calling g_thread_init() didn't seem to have any effect at all.

So if one would to take this as a fact, please do force initializing
threading as it is actually faster than without on my Ubuntu 9.10! :)

But I'm totally not sure if the test is sane or reliable.

Kalle Vahlman, zuh iki fi
Powered by
Interesting stuff at
See also

Attachment: test.c
Description: Binary data

Attachment: res
Description: Binary data

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