From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7644 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Eliminating preference for avoiding thread pointer? Cost on MIPS? Date: Sat, 16 May 2015 02:19:33 -0400 Message-ID: <20150516061933.GI17573@brightrain.aerifal.cx> References: <20150516035544.GA4274@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431757189 25272 80.91.229.3 (16 May 2015 06:19:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2015 06:19:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7656-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 16 08:19:49 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YtVRs-0001G4-C3 for gllmg-musl@m.gmane.org; Sat, 16 May 2015 08:19:48 +0200 Original-Received: (qmail 25600 invoked by uid 550); 16 May 2015 06:19:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24550 invoked from network); 16 May 2015 06:19:45 -0000 Content-Disposition: inline In-Reply-To: <20150516035544.GA4274@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7644 Archived-At: On Fri, May 15, 2015 at 11:55:44PM -0400, Rich Felker wrote: > Traditionally, musl has gone to pretty great lengths to avoid > depending on the thread pointer. The original reason was that it was > not always initialized, and when it was, the init was lazy. This > resulted in a lot of cruft, where we would have lots of constructs of > the form: > > bar = some_predicate ? __pthread_self()->foo : global_foo > > or similar. Being that these predicates depend(ed) on globals, they > were/are rather expensive in position-independent code on most archs. > Now that the thread pointer is always initialized at startup (since > 1.1.0) and assumed to have succeeded (since 1.1.9; musl now performs > HCF if it fails), this seems to be an unnecessary cost. Not only does > it cost cycles; it also has a complexity cost in terms of code to > maintain the state of the predicates (e.g. the atomics for locale > state) and in terms of libc-internal assumptions. So I'd like to just > use the thread pointer directly wherever it makes sense, and take > advantage of the fact that we have it. > > [...] > > So I think, whatever the performance results end up being, we have an > acceptable path forward to use the (possibly virtual) thread pointer > unconditionally throughout musl. Just committed the first stage of this work: http://git.musl-libc.org/cgit/musl/commit/?id=68630b55c0c7219fe9df70dc28ffbf9efc8021d8 If there are old-MIPS performance regressions we'll fix them at the arch level rather than keeping this cruft all over the source. Rich