Results 1 to 2 of 2

Thread: question re libm [related to: Executable running slower on opensuse12.3]

  1. #1
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default question re libm [related to: Executable running slower on opensuse12.3]


    Based on the thread "Executable running slower on opensuse 12.3" and
    some posts from a_jaeger:

    > on this post


    >>> There might still be some slowdown for certain inputs since glibc's
    >>> software routines are used instead of the inaccurate sin x87 instruction
    >>> - just less dramatic as the numbers above show. But you'll get better
    >>> precision

    >>
    >> You mean that some of the hardware cpu math instructions are
    >> inaccurate,
    >> and thus we have to use again software implementations, as we did 20
    >> years ago before the math coprocesor was invented? That's a shame

    >
    > Yes, exactly. The Intel manual explains these limitations on sine and
    > cosine.



    I understood that the entire sine and cosine functions in libm are
    implemented in software, not using at all the sin/cos hardware
    instructions of the "coprocesor" (which is no longer a separate unit
    since many years).

    A friend of mine argues that is impossible, that he understand that for
    certain input values are calculated in hardware and certain others are
    in software.

    Can somebody clarify this point, please?

    There is a mention of a manual, but I don't know which. Link, perhaps?

    We'd be also interested in knowing to what extent does libm use the
    coprocesor functions (I don't really know how to call them).

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.3 x86_64 "Dartmouth" at Telcontar)

  2. #2

    Default Re: question re libm [related to: Executable running slower onopensuse 12.3]

    On 2013-12-18, Carlos E. R. <robin_listas@no-mx.forums.opensuse.org> wrote:
    > I understood that the entire sine and cosine functions in libm are
    > implemented in software, not using at all the sin/cos hardware
    > instructions of the "coprocesor" (which is no longer a separate unit
    > since many years).
    >
    > A friend of mine argues that is impossible,


    Of course your friend is incorrect. There are many different ways to calculate sines and cosines using software e.g. see
    http://sourceware.org/git/?p=glibc.g..._sin.c;hb=HEAD -- which uses the inefficient
    Taylor seres method. I'd assume the software implementation in libm uses the gold standard Payne and Hanek method.

    > that he understand that for
    > certain input values are calculated in hardware and certain others are
    > in software.


    Implementing comparator operations to test for certain input values seems both arbitrary and inefficient.

    > Can somebody clarify this point, please?


    I think you need to ask your friend to clarify his/her point e.g. what is the criteria that deems the input value
    appropriate for hardware or software calculation? You should ask him/her for a reference. As far as I can see, libm is
    all software-calculated unless you compile with certain flags (which don't work for me anyway).

    > There is a mention of a manual, but I don't know which. Link, perhaps?


    I find official documentation of this kind of thing thin on the ground. If you Google Christoph Lauter and/or Joseph Myers,
    you can usually find some discussion on the matter.

    > We'd be also interested in knowing to what extent does libm use the
    > coprocesor functions (I don't really know how to call them).


    To my knowledge, the only way to call floating point unit instructions directly (rather than for example using SSE2
    intrinsics) is using assembler or inline assembler.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •