I believe there was but IMHO calling the libm library function is the
better solution, as discussed in the previous emails below. Less
maintenance, less testing, and possibly better performance, e.g. as
explained here
<https://software.intel.com/en-us/articles/using-avx-without-writing-avx-code>:
the C compiler used to produce libm may generate appropriate 128 and
256-bit Intel AVX VEX-encoded instructions,  generating multiple,
processor-specific, auto-dispatched code paths when there is a performance
benefit. The most appropriate code would be executed at run time.

Cheers
George

On Thu, Aug 2, 2018 at 5:19 PM David Feuer <da...@well-typed.com> wrote:

> Wasn't there a very recent commit to improve these functions, by
> leftaroundabout?
>
> On Thursday, August 2, 2018 8:16:10 AM EDT Artem Pelenitsyn wrote:
> > Here is the patch: https://phabricator.haskell.org/D5034
> >
> > --
> > Best, Artem
> >
> > On Thu, 2 Aug 2018 at 06:26 Artem Pelenitsyn <a.pelenit...@gmail.com>
> wrote:
> >
> > > I'd be willing to do this.
> > >
> > > --
> > > Best wishes,
> > > Artem
> > >
> > >
> > > On Thu, 2 Aug 2018, 04:38 Matt Peddie, <mped...@gmail.com> wrote:
> > >
> > >> Thanks, Ben, for chiming in.  I think calling out to C for these
> > >> functions is the way to go if it's now feasible.  (Calling out to libm
> > >> is the workaround I'm using in the application that led me to discover
> > >> the inaccuracy.)
> > >>
> > >> Matt
> > >>
> > >> On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari <b...@smart-cactus.org>
> wrote:
> > >> > Matt Peddie <mped...@gmail.com> writes:
> > >> >
> > >> >> Hi George,
> > >> >>
> > >> >> Not a stupid question.  I don't have a single source at hand, but I
> > >> >> think I read in a few places on the wiki that calling out to the
> > >> >> system math library is not an option due to the variety of system
> math
> > >> >> libraries on the platforms GHC supports.  It'd be great if I got
> the
> > >> >> wrong impression and this could just be a call to C.  Can anyone
> set
> > >> >> me straight on this point?
> > >> >>
> > >> > Indeed it's not a stupid question at all. Indeed this is precisely
> what
> > >> > we do for the simpler transcendentals (e.g. sin, asin, log). We very
> > >> > well could move in this direction in the case of asinh/atanh as
> well. I
> > >> > believe the reason we don't currently is that atanh was only
> > >> > standardized in C99, which we only started requiring a few releases
> ago.
> > >> > Perhaps this is ultimately the right direction.
> > >> >
> > >> > Cheers,
> > >> >
> > >> > - Ben
> > >> _______________________________________________
> > >> ghc-devs mailing list
> > >> ghc-devs@haskell.org
> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > >>
> > >
> >
>
>
> --
> David Feuer
> Well-Typed
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to