Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Radians Or Degrees?
Date: Thu, 21 Mar 2024 00:03:48 +0200
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <20240321000348.00004b37@yahoo.com>
References: <ur5trn$3d64t$1@dont-email.me>
	<ur5v05$3ccut$1@dont-email.me>
	<20240222015920.00000260@yahoo.com>
	<ur69j9$3ftgj$3@dont-email.me>
	<ur86eg$1aip$1@dont-email.me>
	<ur88e4$1rr1$5@dont-email.me>
	<ur8a2p$2446$1@dont-email.me>
	<ur8ctk$2vbd$2@dont-email.me>
	<20240222233838.0000572f@yahoo.com>
	<3b2e86cdb0ee8785b4405ab10871c5ca@www.novabbs.org>
	<ur8nud$4n1r$1@dont-email.me>
	<936a852388e7e4414cb7e529da7095ea@www.novabbs.org>
	<ur9qtp$fnm9$1@dont-email.me>
	<20240314112655.000011f8@yahoo.com>
	<jwv1q87l5ou.fsf-monnier+comp.arch@gnu.org>
	<9a5b9a6a445bd41ff75a93b589982970@www.novabbs.org>
	<jwv8r2djafq.fsf-monnier+comp.arch@gnu.org>
	<20240320182147.000067e1@yahoo.com>
	<874a1d36b91024222a126fbedb677615@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="81d7bc9a7495271f9790b1be0b3006b0";
	logging-data="1791105"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19cyZYeuCyvAojJd1kynwfnymVHzC/TqE0="
Cancel-Lock: sha1:aIrOBE91mjbDy8uj4TTMpCWGk9E=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4067

On Wed, 20 Mar 2024 20:33:44 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
> 
> > On Wed, 20 Mar 2024 09:54:36 -0400
> > Stefan Monnier <monnier@iro.umontreal.ca> wrote:  
> 
> >> [ Their key insight is the idea that to get correct rounding, you
> >>   shouldn't try to compute the best approximation of the exact
> >> result and then round, but you should instead try to compute any
> >>   approximation whose rounding gives the correct result.  ]
> >> 
> >> My impression was that their performance was good enough that the
> >> case for not-correctly-rounded implementations becomes very weak.
> >>  
> 
> > It all depend of what you compare against.
> > For scalar call for majority of transcendental functions on IEEE-754
> > list, it's probably very easy to get correctly rounded binary32
> > results in approximately the same time as results calculated with
> > max. err of, say, 0.75 ULP. Especially so if target machine has
> > fast binary64 arithmetic.  
> 
> > But in practice when we use lower (than binary64) precision we often
> > care about vector performance rather than scalar.
> > I.e. we care little about speed of sinf(), but want ippsTone_32f()
> > as fast as possible. In case you wonder, this function is part Intel
> > Performance Primitives and it is FAST. Writing correctly rounded
> > function that approaches the speed of this *almost* correctly
> > rounded routine (I think, for sane input ranges it's better than
> > 0.55 ULP) would not be easy at all!  
> 
> I challenge ANY software version of SIN() correctly rounded or not
> to compete with my <patented> HW implementations for speed (or even
> power).
>

Before you post this response, you could as well look at what
ippsTone_32f() is doing. Hint - it's not generic scalar sin().
IMHO, for long enough vector and on modern enough Intel or AMD CPU it
will very easily beat any scalar-oriented binary64-oriented HW
implementation of sin() or cos().
This function is not about latency. It's about throughput.

AFAIR, youu were quite surprised by speed (throughput) of another IPP
primitive, ippsSin_64f_A53() when I posted results of timing
measurement here less than 2 yeears ago. So, before you issue a
challenge, just take into account that ippsTone_32f() is both more
specialized than ippsSin_64f_A53() and has much lower precision. So,
while I didn't test, I expect that it is much much faster.