Am 26.03.2013 21:16, schrieb ZStefan:
> What is the replacement strategy then?
I would not replace anything which is part of glibc as the whole system
depends on glibc. Either wait for the bugfix or if it is important to
have the speed back right now use 12.2 until it is solved.
Just my 2 ct otherwise you may break a vital part of the system without
noticing it first.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.0 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
On Tue, 26 Mar 2013 00:16:01 +0000, ZStefan wrote:
> “But I note as well that gcc’s rewrite in C++ was completed recently,
> and as the compiler evolves, different optimizations may be affected
> by changes in the compiler code.”
>
> This looks more like deoptimization rather than optimization. Why was
> the badly functioning product (perhaps the gcc C or C++ compiler, but
> the reason may lie somewhere else) released and why was it picked up and
> distributed in opensuse 12.3? Didn’t the authors know that the compiled
> executable runs twice (!) slower?
I didn’t mention the rewrite because I think that’s the case here - that
rewrite is for the 4.8 release of gcc, IIRC - but the folks who maintain
gcc have years of experience in compiler development that I don’t, so
you’d have to ask them about the impact of the rewrite on code that’s
compiled.
> I can imagine how painful it would be to install the older or newest
> versions of gcc in opensuse 12.3. It is likely not possible. But if
> possible, here’s my wish to opensuse Build Service: please make
> available a rollback or rollforward to better versions of gcc, g++,
> kernel, glibc or whatever the culprit is.
Anyone can set up a build service account and maintain their own version.
> I have submitted a report on Novell’s bugzilla, the number is 811546.
> The details on kernel, compiler and execution speeds are there.
That’s good, but as I said before, specific limited code that
demonstrates the problem is the most effective way to get the issue
identified - and that may need to be pushed upstream to the gcc project.
Am 26.03.2013 22:44, schrieb Jim Henderson:
> and that may need to be pushed upstream to the gcc project.
glibc is not maintained by the gcc project, it is a project on its own.
You can compile the code snippet which shows the problem in this thread
as effective as you want, this will not matter at all, it is not the
code generated which is slow, it is the cos function in the 2.17 libm
which is unbelievably slow compared to earlier versions.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.0 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
On 2013-03-26 22:44, Jim Henderson wrote:
> That’s good, but as I said before, specific limited code that
> demonstrates the problem is the most effective way to get the issue
> identified - and that may need to be pushed upstream to the gcc project.
It is on another post
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
This is true, but exp() is slow as well, though to a lesser degree.
The program below was compiled and run to work with cos() only or with exp() only, in opensuse 12.3 and 12.2. Here are the execution times:
-------------- Execution times in seconds --------------------
OS = opensuse_12.3 opensuse_12.2
FN = cos 29.5 11.5
FN = exp 6.8 4.0
--------------------------------------------------------------
// Version 2.0
//
// Compilation command:
// g++ -Wall -Wextra -O2 check_speed.C
// Set the desired function in #define below
# include <cstdlib>
# include <iostream>
# include <cmath>
#define FN cos
//#define FN exp
using namespace std;
//-----------------------------------------------
int main() // Purpose: measure execution speed.
{
const int NX=1000000, NY=60;
double x=-3.3, y=0.0;
int j = 99;
for(int i=0; i<NX; i++)
{
x = 3.0 + i + FN(-i-j); // x > 0
for(j=0; j<NY; j++)
{
y = 2.0 + 0.01*FN(-j-2*i-x); // y > 0
y = 1.3 + 400*y + FN(-y - x - i/10); // y > 0
x += 2.5 + i + 2000*FN(-y-x-i)*FN(-y-x-i) +
5000*FN(-i-1000*j)*FN(-i-1000*j) + y; // x > 0
x = 12 - FN(y-x-i);
}
}
x = x + y + j;
cout << "x = " << x << endl;
return 0;
}
There is a factory version available: glibc-2.17-10.2.x86_64. This version is of slightly higher number than the installed glibc-2.17-4.4.1.x86_64 and contained some hope in it.
With minor --force, it is possible to install the Factory version in opensuse 12.3.
However, the version glibc-2.17-10.2.x86_64 has the same library file /lib64/libm-2.17.so that
glibc-2.17-4.4.1.x86_64 has, and produces the same execution speeds.
On Tue, 26 Mar 2013 22:03:06 +0000, Carlos E. R. wrote:
> On 2013-03-26 22:44, Jim Henderson wrote:
>> That’s good, but as I said before, specific limited code that
>> demonstrates the problem is the most effective way to get the issue
>> identified - and that may need to be pushed upstream to the gcc
>> project.
>
> It is on another post
On Tue, 26 Mar 2013 21:56:05 +0000, Martin Helm wrote:
> Am 26.03.2013 22:44, schrieb Jim Henderson:
>> and that may need to be pushed upstream to the gcc project.
>
> glibc is not maintained by the gcc project, it is a project on its own.
Sure, I hadn’t read as far in the thread as the samples that were done.
If it were a compiler issue, then the proper place to report it would be
the compiler, not glibc. But it sounds like it is a library issue, so
where it’s been reported is good.
> You can compile the code snippet which shows the problem in this thread
> as effective as you want, this will not matter at all, it is not the
> code generated which is slow, it is the cos function in the 2.17 libm
> which is unbelievably slow compared to earlier versions.
And that’s well identified - so hopefully someone can figure out what the
issue is and get an update that fixes it.
Am 27.03.2013 07:46, schrieb ZStefan:
> Don’t know whether it is relevant or not, but the slowdown bug has not
> been reported to the GNU C Library (glibc) project.
> It has been reported to Novell’s bugzilla, to opensuse 12.3 product.
I think that is the right place as the packagers need to check if it is
an openSUSE specific problem or an upstream problem first
To see if it is an upstream prblem someone would need at least to see if
another distro with glibc 2.17 has the same slowdown.
My personal workaround to avoid screwing my system is at the moment to
use LD_PRELOAD for scientific calculations and software (like octave,
scipy, self compiled software …).
I copied libm-2.15.so to /lib64/ (it does not do any harm as it is not
symlinked somewhere) and invoke programs with
LD_PRELOAD=/lib64/libm-2.15.so octave
just to give an example. So far it works fine and I have the speedup
where I need it.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.0 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
IMHO that is not so easy to do, as openSUSE is a bit on the cutting edge side of things here. I note:
Fedora 18 has the 2.16.0 glibc (one needs the relatively unstable Fedora Rawhide to get 2.17)
Linux Mint-14 has the 2.15 glibc (i.e. forget any idea of an easy 2.17 test with Linux Mint)
Mageia-2 has the 2.14.1 glibc (one needs the relatively unstable Mageia Cauldron to get 2.17)
Ubuntu-12.10 has the 2.15 glibc (one needs the relatively unstable Ubuntu snapshot Raring to get the 2.17)
Debian sid has 2.13 glibc…
Arch “current” has 2.14 glibc
PC Linux OS 2013.03.26 has the 2.13 glibc
I started looking at kernel versions some weeks back when testing a graphics problem with nouveau, and it was only then when comparing packages in different GNU/Linux versions, that I realized how much more cutting edge a new openSUSE release tends to be (relative to other GNU/Linux distributions).
Am 27.03.2013 05:06, schrieb ZStefan:
>
> I looked at glibc’s bug report pages:
>
> ‘The GNU C Library’ (http://www.gnu.org/software/libc/bugs.html)
>
> As it appears, the slowdown bugs are common, perhaps appearing several
> times a year. Particularly unlucky are functions sine and power.
>
> It may take years to figure out a bug. Here is an example:
>
> “Slow sine function for special values on AMD64 - second
> attempt” (2008-2012)
>
>
Yeah and this one
Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions http://sourceware.org/bugzilla/show_bug.cgi?id=14412
retargeted for 2.18
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.0 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
I don’t have an openSUSE 12.2 box in front of me (yet!) to test, but I suspect part of the answer may be premature optimisation' within the cmath library. Looking at the assembler from SIMD and FPU compiles, it looks like subroutines are called (e.g. call cos’) that may be more inefficient than using simple floating point instructions (e.g. fsin,
fcos, are there SIMD equivalents nowadays?). It’s just a hunch, but I can’t be sure without checking the assembler
generated from openSUSE 12.2 (i.e from g++ -S code.cpp).
