From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10542 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Model specific optimizations? Date: Sat, 1 Oct 2016 01:50:23 -0400 Message-ID: <20161001055023.GA24569@brightrain.aerifal.cx> References: <20160929142126.GB22343@voyager> <20160929152354.GK19318@brightrain.aerifal.cx> <20160929170801.GC22343@voyager> <20160929181336.GL19318@brightrain.aerifal.cx> <20160930045615.GD22343@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1475301057 12223 195.159.176.226 (1 Oct 2016 05:50:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Oct 2016 05:50:57 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10555-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 01 07:50:54 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bqDC1-0000eY-CV for gllmg-musl@m.gmane.org; Sat, 01 Oct 2016 07:50:37 +0200 Original-Received: (qmail 3495 invoked by uid 550); 1 Oct 2016 05:50:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3458 invoked from network); 1 Oct 2016 05:50:35 -0000 Content-Disposition: inline In-Reply-To: <20160930045615.GD22343@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10542 Archived-At: On Fri, Sep 30, 2016 at 06:56:15AM +0200, Markus Wichmann wrote: > On Thu, Sep 29, 2016 at 02:13:36PM -0400, Rich Felker wrote: > > On Thu, Sep 29, 2016 at 07:08:01PM +0200, Markus Wichmann wrote: > > > [...] > > On Linux it's supposed to be the kernel which detects availability of > > features (either by feature-specific cpu flags or translating a model > > to flags) but I don't see anything for fsqrt on ppc. :-( How/why did > > they botch this? > > > > Maybe it's a new extension? I only know version 2.2 of the PowerPC Book. > > Or maybe it goes back to the single core thing. (Only the 970 supports > it, and that's pretty new.) Or maybe Linux kernel developers aren't > interested in this problem, because a manual sqrt exists, and if need > be, anyone can just implement the Babylonian method for speed. On PPC, > it can be implemented in a loop consisting of four instructions, namely: > > ; .rodata > half: .double 0.5 > ; assuming positive finite argument > ; if that can't be assumed, go through memory to inspect argument > fmr 1, 0 ; yes, halving the exponent would be a better estimate > ; requires going through memory, though > lfd 2, half(13) > li 0, 6 ;or more for more accurcy > mtctr 0 > > 1: ; fr0 = x, fr1 = a > fdiv 3, 1, 0 ; fr3 = a/x > fadd 3, 3, 0 ; fr3 = x + a/x > fmul 0, 3, 2 ; fr0 = 0.5(x + a/x) > bdnz 1b > > So maybe there wasn't a lot of need for the hardware sqrt. I don't think this works at all. sqrt() is required to be correctly-rounded; that's the whole reason sqrt.c is costly. > > > Well, yes, I was just throwing shit at a wall to see what sticks. We > > > could also move the function pointer dispatch into a pthread_once block > > > or something. I don't know if any caches need to be cleared then or not. > > > > pthread_once/call_once would be the nice clean abstraction to use, but > > it's mildly to considerably more expensive, currently involving a full > > barrier. There's a nice technical report on how that can be eliminated > > but it requires TLS, which is also expensive on some archs. In cases > > like this where there's no state other than the function pointer, > > relaxed atomics can simply be used on the reading end and then they're > > always fast. > > Hmmm... not on PPC, though. TLS on Linux PPC just uses r2 as TLS > pointer. So the entire thing could be used almost as-is by making sqrtfn > thread-local? Yes and no. Not in musl because we don't use _Thread_local; it would require allocating space in the thread structure which is not appropriate for something like this. The right and most efficient solution is the one I described above. Rich