From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Trigonometric operations on x86 and x64 CPUs Date: Fri, 16 Dec 2016 14:16:23 -0600 Organization: JSA Research & Innovation Message-ID: References: <8d0f7f03-9324-4702-9100-d6b8a1f16fc5@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1481919384 20533 24.196.82.226 (16 Dec 2016 20:16:24 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 16 Dec 2016 20:16:24 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original Xref: news.eternal-september.org comp.lang.ada:32890 Date: 2016-12-16T14:16:23-06:00 List-Id: "Robert Eachus" wrote in message news:8d0f7f03-9324-4702-9100-d6b8a1f16fc5@googlegroups.com... >A while back I expressed surprise that there were no versions of the >Elementary_Functions package for x86/x64 packages which used the >built-in trig functions of the x86 family. It looked like an easy project >but... Why? Janus/Ada has always (*) had such a package. It's no problem with a 32-bit compiler. (Still don't know why anyone would need more than that much address space anyway.) (*) OK, not in the earliest integer-only compilers. But: (1) We don't use it for Generic_Elementary_Functions because it's impossible to be sure that the built-in instructions meet that Annex G accuracy requirements. (2) Intel's documentation way back when made it clear that you had to do argument reduction first (yourself). The instructions were not intended to be accurate for values outside of +/- 2*PI (or something like that, I'm writing this from memory). (3) Argument reduction is always going to lose a lot of precision for large values, when you start with a 64 bit value there isn't going to be much left if the value is large. Hard to blame that mathematical fact on the hardware. (4) Intel doesn't seem to have done anything performance-wise for these instructions. Last time I checked, they were only a few times faster than the usual software approximation. Not enough to make them useful outside of the most time-critical application. (Perhaps some preconditions would help here, as a lot of the cost is checking that the values are in range before applying the hardware operation. Moving that to the call-site would allow it to be eliminated.) In any case, in general, I'd trust the Ada implementer to have looked at the issues and having come up with the best possible implementation on the hardware. They have a lot more at stake than any individual user (and a lot more tools as well). If they're not using something, most likely it's because of a good reason or two or six. :-) Randy.