[opensuse-factory] Math code runs half as slow in 12.3 compared to previous versions.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
In here http://forums.opensuse.org/showthread.php?t=484988 it has been
found that the "libm" library is faulty, makes code run half as slow, in
several distros, compared to previous version. Brute force replacing the
libm library in 12.3 with that of 12.2 solves the issue.
Sample code:
// Version 1.0
//
// Compilation command:
// g++ -Wall -Wextra -O2 check_speed.C
# include <cstdlib>
# include <iostream>
# include <cmath>
using namespace std;
//----------------------------------------------
int main() // Purpose: measure execution speed.
{
const int NX=1000000, NY=8;
double x=-3.3, y=0.0, z=9.4;
int j = 99;
for(int i=0; i
On 04/09/2013 01:27 PM, Carlos E. R. wrote: e >Brute force replacing the
libm library in 12.3 with that of 12.2 solves the issue.
Advice people to never do that, that's crazy and might break their systems. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-09 at 13:40 -0300, Cristian Rodríguez wrote:
libm library in 12.3 with that of 12.2 solves the issue.
Advice people to never do that, that's crazy and might break their systems.
They know that, but it proves the regression in the code. The current suggestion is to regress the glibc library to 2.15. I believe you know more about glibc than many people, so perhaps you can suggest a better method to solve the problem. Test the code yourself, it is twice as slow. I suggest you read that entire forum thread before replying. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFkRlkACgkQtTMYHG2NR9XkNwCgk0waZTEqEic18y/4qwyXEqsq 1roAn18rGrMavrqY2OLJE+0TAO4sXDqJ =npXz -----END PGP SIGNATURE-----
On 04/09/2013 06:27 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
In here http://forums.opensuse.org/showthread.php?t=484988 it has been found that the "libm" library is faulty, makes code run half as slow, in several distros, compared to previous version. Brute force replacing the libm library in 12.3 with that of 12.2 solves the issue.
This looks like a regression in upstream glibc. glibc 2.17 has many improvements in standard conformance and accuracy and might have lost performance here. Getting the code smaller to figure out a single function that fails would help even more.
[...] There is a bugzilla:
https://bugzilla.novell.com/show_bug.cgi?id=811546
There is still no official response.
What do you mean with "official"? What is your expectation here? Regarding response: There were a couple of questions raised and answered and this week is hackweek, so the assignee might look at other stuff. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-09 at 18:50 +0200, Andreas Jaeger wrote:
This looks like a regression in upstream glibc. glibc 2.17 has many improvements in standard conformance and accuracy and might have lost performance here. Getting the code smaller to figure out a single function that fails would help even more.
Read the forum thread. Ask them. They point at sin() and others. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFkSBgACgkQtTMYHG2NR9UxpQCggVKkx0h717bFGgd0+s+3ziUs +nEAnAv6FOpYPv56w6l8Q1FnEyPDXvU8 =It7f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I just looked at bit at this and added the following text to the forum threads, Andreas As one of the upstream glibc developers and openSUSE packagers, let me chime into this discussion: Upstream glibc contains many changes for the math library so that it is standard conform also in all corner cases and accurately calculates numbers - the goal is accuracy for all digits. This might lead in some cases to slower runtime execution. For the upstream sin/cos bugs that changed this behaviour for sin and cos, see http://sourceware.org/bugzilla/show_bug.cgi?id=13658. Glibc developers are aware that some functions are slower and have started now with addressing some of that slowness and reached already some improvements. Also, glibc now contains a benchmark test suite that can be run before/after making changes to check that we do not introduce slowdowns by accident. If you read comment 4 of http://sourceware.org/bugzilla/show_bug.cgi?id=13932, the worst case performance of pow has been improved already 4 times. Coming back to sin/cos: Previously the fsincos hardware instruction was used and it is highly inaccurate for larger values - and therefore we had to use a software implementation. -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-09 at 20:11 +0200, Andreas Jaeger wrote:
I just looked at bit at this and added the following text to the forum threads,
Thanks a lot! :-)
Coming back to sin/cos: Previously the fsincos hardware instruction was used and it is highly inaccurate for larger values - and therefore we had to use a software implementation.
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 :-( - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFki7kACgkQtTMYHG2NR9W/EwCfUVdwNBwF31ESbRYC2lKVhyPU xpgAmwQz1Roi7blGgU7xC0B7ICp6y4XI =WeYO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 09/04/13 18:44, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2013-04-09 at 20:11 +0200, Andreas Jaeger wrote:
I just looked at bit at this and added the following text to the forum threads,
Thanks a lot! :-)
Coming back to sin/cos: Previously the fsincos hardware instruction was used and it is highly inaccurate for larger values - and therefore we had to use a software implementation.
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 :-(
There is -ffast-math compile option for cases that you dont need/want high precision. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-09 at 20:00 -0300, Cristian Rodríguez wrote:
El 09/04/13 18:44, Carlos E. R. escribió:
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 :-(
There is -ffast-math compile option for cases that you dont need/want high precision.
Ah, well, that's some thing. But still, it is a shame that we can not use HW functions if we need reliability, don't you think? And of course, it may happen that different processor brands and models can yield different results, no? This is terrible! I'm not blaming glibc devs on this, they are doing the correct thing. I hope that you can choose at compile time HW speed, fast software functions, or absolutely accurate software. But that the hardware math functions in the processors are inaccurate is an absolute shame! (I have been disconnected from this side of things for many years, so this took me by surprise. I remember long ago when the Intel "coprocessor" was found to do bad math... I though that was long past). - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFkrT0ACgkQtTMYHG2NR9WzfgCfU7egop/RYCSUGoe+h7dvA05P 2oQAnROS6txdjGyxnCnCiBIOY+weUzt1 =8F2L -----END PGP SIGNATURE-----
On Tue, Apr 9, 2013 at 9:07 PM, Carlos E. R.
On Tuesday, 2013-04-09 at 20:00 -0300, Cristian Rodríguez wrote:
El 09/04/13 18:44, Carlos E. R. escribió:
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 :-(
There is -ffast-math compile option for cases that you dont need/want high precision.
Ah, well, that's some thing.
But still, it is a shame that we can not use HW functions if we need reliability, don't you think? And of course, it may happen that different processor brands and models can yield different results, no?
This is terrible!
I'm not blaming glibc devs on this, they are doing the correct thing. I hope that you can choose at compile time HW speed, fast software functions, or absolutely accurate software.
But that the hardware math functions in the processors are inaccurate is an absolute shame!
Actually, the OP links show that it's not that they're "innaccurate" per-se, it's stated on the IA docs (and I do remember reading that, though I didn't find it now when I re-checked) that it's designed to be used within the -Pi/2..Pi/2 range, and using the instructions outside the range would yield less precise results, that reduction to that range ought to be done in software, with the aid of fprem. Now, not sure what did libm does, but the "fast and wrong" version didn't even call fprem, so I guess the slowdown could come from it (since it has to be invoked in a loop). If not, using fprem may be much faster than invoking libm. I guess this could be testing by calling sincos(fmod(x, M_PI)) on the old, inaccurate gcc version, and checking the result. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-04-10 at 01:20 -0300, Claudio Freire wrote:
Actually, the OP links show that it's not that they're "innaccurate" per-se, it's stated on the IA docs (and I do remember reading that, though I didn't find it now when I re-checked) that it's designed to be used within the -Pi/2..Pi/2 range, and using the instructions outside the range would yield less precise results, that reduction to that range ought to be done in software, with the aid of fprem.
Ah, that makes sense.
Now, not sure what did libm does, but the "fast and wrong" version didn't even call fprem, so I guess the slowdown could come from it (since it has to be invoked in a loop). If not, using fprem may be much faster than invoking libm.
I guess this could be testing by calling sincos(fmod(x, M_PI)) on the old, inaccurate gcc version, and checking the result.
In the forum thread I mentioned at the start there are some posts listing other math libraries, some commercial, that give better results. But it needs rebuild of the affected applications, of course. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFlMp0ACgkQtTMYHG2NR9VwKQCdHL0Sx0KpRJzydOiQO1soLizg ze8AnRppHYPZTx+919VvrmDwaWsCpnBi =C0eO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 10, 2013 at 6:36 AM, Carlos E. R.
Now, not sure what did libm does, but the "fast and wrong" version didn't even call fprem, so I guess the slowdown could come from it (since it has to be invoked in a loop). If not, using fprem may be much faster than invoking libm.
I guess this could be testing by calling sincos(fmod(x, M_PI)) on the old, inaccurate gcc version, and checking the result.
In the forum thread I mentioned at the start there are some posts listing other math libraries, some commercial, that give better results. But it needs rebuild of the affected applications, of course.
Besides the horrible typos in my post, I did try, on 12.2 and 11.4, and couldn't find evidence of fmod helping in any way (though it did change results, not sure it was for the better or worse), nor of sin and sincos disagreeing at any point, as per the OP bug report. In essence, I could not reproduce the bug. sin and sincos always agreed. If the results were right or not, I could not tell. I'll have to carefully implement power series expansion to test that, and though I might do it just for the lulz, it might be over my enthusiasm level ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-04-10 at 11:57 -0300, Claudio Freire wrote:
On Wed, Apr 10, 2013 at 6:36 AM, Carlos E. R. <> wrote:
In the forum thread I mentioned at the start there are some posts listing other math libraries, some commercial, that give better results. But it needs rebuild of the affected applications, of course.
Besides the horrible typos in my post, I did try, on 12.2 and 11.4, and couldn't find evidence of fmod helping in any way (though it did change results, not sure it was for the better or worse), nor of sin and sincos disagreeing at any point, as per the OP bug report.
The speed problem appears with 12.3, neither 11.4 nor 12.2 are affected. Or at least not so dramatically. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFlhnAACgkQtTMYHG2NR9W5jgCfYBnAxnV7hNp3XiEluuISthRX 3k0An3DKydrJ9XpNXAf9ekbuZ77A6zoF =BB7V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 10, 2013 at 12:34 PM, Carlos E. R.
On Wednesday, 2013-04-10 at 11:57 -0300, Claudio Freire wrote:
On Wed, Apr 10, 2013 at 6:36 AM, Carlos E. R. <> wrote:
In the forum thread I mentioned at the start there are some posts listing other math libraries, some commercial, that give better results. But it needs rebuild of the affected applications, of course.
Besides the horrible typos in my post, I did try, on 12.2 and 11.4, and couldn't find evidence of fmod helping in any way (though it did change results, not sure it was for the better or worse), nor of sin and sincos disagreeing at any point, as per the OP bug report.
The speed problem appears with 12.3, neither 11.4 nor 12.2 are affected. Or at least not so dramatically.
Yeah, but the precision problem should... right? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, April 09, 2013 23:44:12 Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2013-04-09 at 20:11 +0200, Andreas Jaeger wrote:
I just looked at bit at this and added the following text to the forum threads,
Thanks a lot! :-)
Coming back to sin/cos: Previously the fsincos hardware instruction was used and it is highly inaccurate for larger values - and therefore we had to use a software implementation.
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, some of them - in this case it's sine and cosine, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andreas Jaeger -
Carlos E. R. -
Carlos E. R. -
Claudio Freire -
Cristian Rodríguez