Launchpad has imported 6 comments from the remote bug at http://sourceware.org/bugzilla/show_bug.cgi?id=5781.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-02-21T09:10:38+00:00 Petr Cervenka wrote: I would like to repost my previously deleted bug by (lazy IMHO) car...@codesoucery.com. The math sin function is at least 1000x slower on 64bit distributions for special numbers (and carlos dosn't care about it). I can't try it with CVS head, because I cannot connect to cvs through our firewall. But even when I tried the latest snapshot, I couldn't build it (maybe another bug): a - elf/dl-vdso.os : /home/inova/projects/glibc/build/libc_pic.a gcc -nostdlib -nostartfiles -r -o /home/inova/projects/glibc/build/elf/librtld.map.o '-Wl,-(' /home/inova/projects/glibc/build/elf/dl-allobjs.os /home/inova/projects/glibc/build/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/home/inova/projects/glibc/build/elf/librtld.mapT /home/inova/projects/glibc/build/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs' /home/inova/projects/glibc/build/elf/dl-allobjs.os:/home/inova/projects/glibc/src/glibc-20080218/elf/rtld.c:641: first defined here /home/inova/projects/glibc/build/libc_pic.a(dl-addr.os): In function `_dl_addr_inside_object': /home/inova/projects/glibc/src/glibc-20080218/elf/dl-addr.c:158: multiple definition of `_dl_addr_inside_object' /home/inova/projects/glibc/build/elf/dl-allobjs.os:/home/inova/projects/glibc/src/glibc-20080218/elf/dl-open.c:700: first defined here collect2: ld returned 1 exit status make[2]: *** [/home/inova/projects/glibc/build/elf/librtld.map] Error 1 make[2]: Leaving directory `/home/inova/projects/glibc/src/glibc-20080218/elf' make[1]: *** [elf/subdir_lib] Error 2 make[1]: Leaving directory `/home/inova/projects/glibc/src/glibc-20080218' make: *** [all] Error 2 Please, anyone with 64bit distribution and glibc CVS head, could you try the attached example and post the time results of it? (or help me to build the snapshot...) Thank you ====== Original bug report ====================================== The math sin(double) function is in 64bit distribution (Kubuntu 7.10 AMD64 and Fedora - unknown version) unreasonable slow (~400 microseconds on Atlon64 X2 4800+!!!) for some special values. In 32bit distribution is everything fine. I captured some of those values: 0.93340582292648832662962377071381 0x3fedde75e36bb000 2.3328432680770916363144351635128 0x4002a9a9bb38add0 3.7439477503636453548097051680088 0x400df39ae0cdf500 3.9225160069792437411706487182528 0x400f615012801950 4.0711651639931289992091478779912 0x401048df854fdc20 4.7858438478542097982426639646292 0x401324b43fe92fc0 5.9840767662578002727968851104379 0x4017efb1d1df52a0 Example: #include <math.h> int main(int argc, char** argv) { volatile double value = 0.93340582292648832662962377071381; volatile double out; int i; for (i=0; i < 20000; i++) out = sin(value); return 0; } Reply at: https://bugs.launchpad.net/glibc/+bug/192134/comments/1 ------------------------------------------------------------------------ On 2008-02-21T09:39:00+00:00 Jakub Jelinek wrote: Most of the double routines in libm come from IBM accurate matematical library, which ensures <= 0.5ulp error. Trigonometric etc. functions are computed using floating point computations, but if the possible error from that is too high, it uses slower multiprecision computation to guarantee ultimate precise result. Guess you just picked some worst-case values. i386 uses the non-precise hardware instructions instead, so doesn't guarantee the <= 0.5ulp precision. Reply at: https://bugs.launchpad.net/glibc/+bug/192134/comments/2 ------------------------------------------------------------------------ On 2008-02-21T17:09:30+00:00 Joseph-codesourcery wrote: Subject: Re: Slow sine function for special values on AMD64 - second attempt On Thu, 21 Feb 2008, jakub at redhat dot com wrote: > which ensures <= 0.5ulp error. Trigonometric etc. functions are > computed using floating point computations, but if the possible error > from that is too high, it uses slower multiprecision computation to > guarantee ultimate precise result. Guess you just picked some worst-case > values. Note that the crlibm developers were willing to contribute their code, an advantage of which is *much* better worst-case performance. Reply at: https://bugs.launchpad.net/glibc/+bug/192134/comments/3 ------------------------------------------------------------------------ On 2008-02-21T17:42:51+00:00 Jakub Jelinek wrote: Yeah, I'm aware of crlibm, I think if it proves itself that it won't be much slower on average, has the same ultimate precision guarantees and faster worst-cases, I don't see a reason why it can't be integrated. It will be a lot of work to integrate it though. Reply at: https://bugs.launchpad.net/glibc/+bug/192134/comments/4 ------------------------------------------------------------------------ On 2008-02-22T09:00:56+00:00 Petr Cervenka wrote: Is there any compile flag or #define, which can disable the <=0.5 ulp precision and the math sin function will use only the fast built-in fp intructions? For our real-time software it is necessary to be "quick", the ultra precision has low priority. Now we are using a workaround: I can put the original argument to long double variable and call sinl function with long double result. Both, the new argument and the result, have to be volatile to disable the compiler optimization of it (probably uses the "fast" sin instead). Results of sin(0.93340582292648832662962377071381) ---------------------------------------------------- distr function value result_type printf_format -------------------------------------------------------------------- 32 sin 0.80365140438773496889268699305831 double "%.32g" 32 sinl 0.80365140438773496889268699305831 double "%.32g" 32 sinl 0.80365140438773491338153576180048 long double "%.32Lg 64 sin 0.80365140438773485787038453054265 double "%.32g" (~ -5.5511151231257827021181583404541e-17 difference from 80bit value) 64 sinl 0.80365140438773496889268699305831 double "%.32g" (~ +5.5511151231257827021181583404541e-17 difference from 80bit value ) 64 sinl 0.80365140438773491338153576180048 long double "%.32Lg" Reply at: https://bugs.launchpad.net/glibc/+bug/192134/comments/5 ------------------------------------------------------------------------ On 2008-07-14T14:16:52+00:00 Petr Cervenka wrote: I'm not the only one with such problems: http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997 I assume that for the 64-bit distribution (x86_64), it should use sin and sinf from i386 arch (sysdeps\i386\fpu\s_sin.S and sysdeps\i386\fpu\s_sinf.S) and only sinl implementation is explicit x86_64. But the sin and sinf are now used as software versions (IBM library). And it's usually bit slower, sometimes MUCH MORE slower (1000x). IBM library is perhaps only emergency implementation (if there is no hw support) and it's not used for "better" (<= 0.5ULP) precision. "The First Step is to Admit You Have a Problem!" Reply at: https://bugs.launchpad.net/glibc/+bug/192134/comments/6 ** Changed in: glibc Importance: Unknown => Medium ** Bug watch added: Sourceware.org Bugzilla #5997 http://sourceware.org/bugzilla/show_bug.cgi?id=5997 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/192134 Title: slow math sin function for some values on amd64 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
