Henri wrote:
glibc implements acos() as the FPU equivalent of atan2(sqrt(1 - x ^ 2), x).
I just looked, and there are several implementations of acos in glibc, and they all seem to very carefully choose how to do it based on how close x is to 1.
This should be fixed on the glibc side as well
Indeed. Have you filed a bug report against glibc yet? I didn't see one at http://sourceware.org/bugzilla/ Please be sure to attach a simple C program that reproduces the problem, or better yet, a patch to add a test case to their test suite.
2008/8/29 Dan Kegel dank@kegel.com:
Henri wrote:
glibc implements acos() as the FPU equivalent of atan2(sqrt(1 - x ^ 2), x).
I just looked, and there are several implementations of acos in glibc, and they all seem to very carefully choose how to do it based on how close x is to 1.
The specific implementation I was talking about is http://sources.redhat.com/git/?p=glibc.git;a=blob;f=sysdeps/i386/fpu/e_acos.... it's NetBSD derived, and it seems at least NetBSD and OpenBSD use the same or a similar implementation. I couldn't quickly find what FreeBSD uses, but I wouldn't be surprised if it uses something like that as well.
This should be fixed on the glibc side as well
Indeed. Have you filed a bug report against glibc yet? I didn't see one at http://sourceware.org/bugzilla/ Please be sure to attach a simple C program that reproduces the problem, or better yet, a patch to add a test case to their test suite.
I tried to create an account on their bugzilla yesterday, but for some reason I never got the confirmation mail. I'll probably try again in a few days. http://sources.redhat.com/bugzilla/show_bug.cgi?id=2540 looks like a similar issue.
On Fri, Aug 29, 2008 at 7:34 AM, Henri Verbeet hverbeet@gmail.com wrote:
I tried to create an account on their bugzilla yesterday, but for some reason I never got the confirmation mail. I'll probably try again in a few days. http://sources.redhat.com/bugzilla/show_bug.cgi?id=2540 looks like a similar issue.
Heh. Looks like they don't care after all, given how they treated that bug. Grumble. Well, at least that bug shows where the testcase might go. And perhaps your bug report, since it shows that user apps are really affected, will resonate a bit more.
Henri Verbeet wrote:
2008/8/29 Dan Kegel dank@kegel.com:
Henri wrote:
glibc implements acos() as the FPU equivalent of atan2(sqrt(1 - x ^ 2), x).
I just looked, and there are several implementations of acos in glibc, and they all seem to very carefully choose how to do it based on how close x is to 1.
The specific implementation I was talking about is http://sources.redhat.com/git/?p=glibc.git;a=blob;f=sysdeps/i386/fpu/e_acos.... it's NetBSD derived, and it seems at least NetBSD and OpenBSD use the same or a similar implementation. I couldn't quickly find what FreeBSD uses, but I wouldn't be surprised if it uses something like that as well.
Wouldn't it make more sense to put the sane acos and asin implementations in libs/port and use them only if the system provided versions are broken? It should be possible to have configure check that. That way we can use the probably optimized versions on the sane systems.
This should be fixed on the glibc side as well
Indeed. Have you filed a bug report against glibc yet? I didn't see one at http://sourceware.org/bugzilla/ Please be sure to attach a simple C program that reproduces the problem, or better yet, a patch to add a test case to their test suite.
I tried to create an account on their bugzilla yesterday, but for some reason I never got the confirmation mail. I'll probably try again in a few days. http://sources.redhat.com/bugzilla/show_bug.cgi?id=2540 looks like a similar issue.
bye michael
2008/8/29 Michael Stefaniuc mstefani@redhat.com:
Wouldn't it make more sense to put the sane acos and asin implementations in libs/port and use them only if the system provided versions are broken? It should be possible to have configure check that. That way we can use the probably optimized versions on the sane systems.
Possibly, but compiling on a sane system doesn't necessarily mean you'll run on a sane system as well. In terms of performance it's all rather suboptimal either way though. Eg. in the case of C&C Generals you enter msvcrt through _CIacos() with a double in %st(0). We then pop that to CPU memory and pass it to MSVCRT_acos(), which passes it to acos(), which pushes it onto the FPU stack again. Performance wise it would make more sense to write our own implementation in asm inside _CIacos() and have MSVCRT_acos() call that.
On Fri, Aug 29, 2008 at 11:15 AM, Henri Verbeet hverbeet@gmail.com wrote:
2008/8/29 Michael Stefaniuc mstefani@redhat.com:
Wouldn't it make more sense to put the sane acos and asin implementations in libs/port and use them only if the system provided versions are broken? It should be possible to have configure check that. That way we can use the probably optimized versions on the sane systems.
Possibly, but compiling on a sane system doesn't necessarily mean you'll run on a sane system as well. In terms of performance it's all rather suboptimal either way though. Eg. in the case of C&C Generals you enter msvcrt through _CIacos() with a double in %st(0). We then pop that to CPU memory and pass it to MSVCRT_acos(), which passes it to acos(), which pushes it onto the FPU stack again. Performance wise it would make more sense to write our own implementation in asm inside _CIacos() and have MSVCRT_acos() call that.
How performance-critical is this stuff? Supporting our own trig routines is a difficult undertaking, not to be taken lightly...
-
Dan Kegel -
Henri Verbeet -
Michael Stefaniuc