From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12206 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: remquo - underlying logic Date: Wed, 6 Dec 2017 11:37:09 +0100 Message-ID: <20171206103708.GA15263@port70.net> References: <20171130185956.GS15263@port70.net> <20171130211713.GT15263@port70.net> 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 1512560654 12228 195.159.176.226 (6 Dec 2017 11:44:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2017 11:44:14 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: musl@lists.openwall.com Original-X-From: musl-return-12224-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 06 12:44:10 2017 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 1eMY2n-0002VT-89 for gllmg-musl@m.gmane.org; Wed, 06 Dec 2017 12:39:17 +0100 Original-Received: (qmail 19604 invoked by uid 550); 6 Dec 2017 10:37:21 -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 19581 invoked from network); 6 Dec 2017 10:37:21 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12206 Archived-At: * Damian McGuckin [2017-12-06 12:17:40 +1100]: > While my exploration with floating point numbers was less than stellar, > I did notice that when > > ex - ey < p (where p is the digits in the significant) > > you can use the > > fma > > routine to compute some appropriately rounded/truncated version of the > quotient for both remquo and fmod. And this appears to not loose any > precision for the obvious reasons. > > > From my limited testing, the speed gain for this extremely limited range > of exponent difference is huge over the standard routine in MUSL. I will do > some more testing and report in detail but it seems to be orders of > magnitude. > > Somebody might want to comment on that sort of approach. it's not clear to me how you use fma (x-(int)(x/y)*y ?), but efficient fma instruction is not available on all targets and the software implementation can be very slow. and i suspect such approach would break fenv correctness. assuming you rely on exact fma result you may need two different implementation depending on FP_FAST_FMA (which is currently missing in musl). (musl is compiled with -std=c99 so x*y+z is not contracted to fma(x,y,z) automatically when the instruction is available, you have to add -ffp-contract=fast if that's what you want, but it might break some code in musl that relies on exact arithmetics, most math code should work either way though.)