This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Failure to dlopen libgomp due to static TLS data


On Fri, Feb 13, 2015 at 09:12:41AM +0000, Andrew Haley wrote:
> On 12/02/15 23:27, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 06:23:12PM +0000, Andrew Haley wrote:
> >> On 02/12/2015 04:16 PM, Rich Felker wrote:
> >>> On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
> >>>> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> >>>>>
> >>>>> This usage is supposed to be deprecated. Why isn't libgomp using
> >>>>> TLSDESC/gnu2 model?
> >>>>
> >>>> Because it is significantly slower.
> >>>
> >>> Seems very unlikely. If storage is allocated in static TLS, TLSDESC is
> >>> almost indistinguishable from IE in performance, even when you run
> >>> artificial benchmarks that do nothing but hammer TLS access. When it
> >>> gets allocated in dynamic TLS, it's somewhat slower, but still
> >>> unlikely to matter for most usage IMO.
> >>
> >> The problem I'm seeing is that dynamic TLS is always used even when not
> >> necessary, and that hurts Java (which accesses TLS 128k times in the first
> >> 500ms or so of execution).  According to lxo his patch fixes that.
> > 
> > Given those numbers, each access would need to be taking 38ns to
> > consume even 1% of the cpu time being spent. I would guess accesses
> > are closer to 5ns for TLSDESC in static area and 10-15ns for dynamic.
> > So I don't think this is a botteneck.
> 
> I'm totally unconvinced by this style of argument.  An efficient system
> is composed of many small optimizations, each apparently insignificant
> in itself.  Your figures indicate that this slowdown may be about 0.5%.
> 0.5% is not small.  I put in a lot of work to gain 0.5%.

It seems misguided to try to save 0.5% of a 500ms startup time by
choosing a hackish TLS model that's going to break for some people,
when the elephant in the room is java. You could make all 500ms
(except maybe 500us) go away by using a proper language/runtime and
get a 99.9% savings.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]