I was rather asking whether some problems we had with the 4.55 Beta (and not occured with the official 4.40) still occur with the 4.58.
BM
My crunchers are headless so the graphics are not used anyway, but I did have modify the .so file on at least one box when using 4.55, but haven't had to do that with 4.58.
Ditto for me. I had to remove the .so file on almost all of my crunchers with 4.55. I don't have to do that on 4.58.
Yes, the main reason is compatibility to old Linux systems that use an old glibc. For that the program is linked with gcc-3.0.4, which, however, doesn't necessarily mean that it has been thoroughly compiled wit it.
The program spends most of its time in the code from a single module that can be compiled with a different compiler than the rest of the program. In the current official 4.40 App this module was compiled with gcc-3.4 which we found to give the fastest code, i.e. faster than of any gcc-4 that was available at that time. In the previous 4.55 Beta App, featuring source code that was written to make use of the auto-vectorizer, we used gcc-4.1.0 for that. In the 4.58 App the most important part is coded in Assembler anyway, so the compiler doesn't make much of a difference. However, this module is still compiled with a gcc-4, which is gcc-4.1.0 if I remember correctly.
Future builds will probably use the new Intel icc compiler (9.1), as it gives slightly faster code than anything I've seen so far from any gcc.
Welcome aboard the good ship Einstein!! I'm really pleased to see you participating here!!
I've been a long time user of your optimised Seti apps and am currently very pleased with the extra performance of your 5.12 over the standard app. Without hijacking this thread, I'd just like to say thanks for your work.
Future builds will probably use the new Intel icc compiler (9.1), as it gives slightly faster code than anything I've seen so far from any gcc.
BM
Thanks for the info, you should consider testing icc 9.0 first. From my point of view
(building S@H apps.) it genrates sometimes faster code.
Using icc myself on windows&linux i also noticed that icc 9.1 compiled code is sometimes 3x the size of icc 9.0 build binaries.
Until now i don't have a clue to that myself.
Quote:
Hey Crunch3r,
Welcome aboard the good ship Einstein!! I'm really pleased to see you participating here!!
I've been a long time user of your optimised Seti apps and am currently very pleased with the extra performance of your 5.12 over the standard app. Without hijacking this thread, I'd just like to say thanks for your work.
Cheers,
____________
Cheers,
Gary.
Thanks Gary.
Bad news is that ther'e won't be any optimized S@H app. any more.
But that's nothing that belongs here.
Using icc myself on windows&linux i also noticed that icc 9.1 compiled code is sometimes 3x the size of icc 9.0 build binaries.
Have you looked at the binary itself with a hex editor or similar? It might be that different code and/or data alignment causes that, or, if you let the icc build code for different CPUs (-ax switch) the 9.1 distinguishes more platforms or inserts CPU switches in more places than the 9.0 does. Do you link glibc or Intel libs? The libraries might make a difference, too.
Last time I tried the icc 9.0 for Einstein@Home it didn't work at all, i.e. the linking failed. It also didn't vectorize the loop that I meant to. The code, however, has changed a bit since then, it might be worth another try now. Thanks for the hint.
Using icc myself on windows&linux i also noticed that icc 9.1 compiled code is sometimes 3x the size of icc 9.0 build binaries.
Have you looked at the binary itself with a hex editor or similar? It might be that different code and/or data alignment causes that, or, if you let the icc build code for different CPUs (-ax switch) the 9.1 distinguishes more platforms or inserts CPU switches in more places than the 9.0 does. Do you link glibc or Intel libs? The libraries might make a difference, too.
Last time I tried the icc 9.0 for Einstein@Home it didn't work at all, i.e. the linking failed. It also didn't vectorize the loop that I meant to. The code, however, has changed a bit since then, it might be worth another try now. Thanks for the hint.
BM
Hi Bernd,
the latests tests using icc on linux (at least for the S@H app.) showed that using intels cxx-lib (-cxxlib-icc) gives worse performance than using glibc, at least on 32bit linux on 64bit it's the other way around.
Quote:
It also didn't vectorize the loop that I meant to.
Have you tried forcing vectorization ?
There are some pragmas you can use in the code to force vectorization of loops.
Is there a special reason for building the beta app with gcc 3.0.4 ?
Is it related to beeing compatible to older linux distributions ?
The reason i'm asking is that gcc 4.X provides superior performance over gcc 3.X.
There has been some fancy stuff added lately like vectorization (-ftree-vectorize ) and it provides generally faster binaries over all.
Welcome, crunch3r
Hope to see you ply your skills here.
Running 'nix 4.58 on several dual and dual-dual opterons with excellent luck so far.
again, welcome.
RE: RE: I was rather
)
Ditto for me. I had to remove the .so file on almost all of my crunchers with 4.55. I don't have to do that on 4.58.
Good work there!
Metod ...
Hello, i'm new here and
)
Hello,
i'm new here and switched to E@H yesterday.
Is there a special reason for building the beta app with gcc 3.0.4 ?
Is it related to beeing compatible to older linux distributions ?
The reason i'm asking is that gcc 4.X provides superior performance over gcc 3.X.
There has been some fancy stuff added lately like vectorization (-ftree-vectorize ) and it provides generally faster binaries over all.
Yes, the main reason is
)
Yes, the main reason is compatibility to old Linux systems that use an old glibc. For that the program is linked with gcc-3.0.4, which, however, doesn't necessarily mean that it has been thoroughly compiled wit it.
The program spends most of its time in the code from a single module that can be compiled with a different compiler than the rest of the program. In the current official 4.40 App this module was compiled with gcc-3.4 which we found to give the fastest code, i.e. faster than of any gcc-4 that was available at that time. In the previous 4.55 Beta App, featuring source code that was written to make use of the auto-vectorizer, we used gcc-4.1.0 for that. In the 4.58 App the most important part is coded in Assembler anyway, so the compiler doesn't make much of a difference. However, this module is still compiled with a gcc-4, which is gcc-4.1.0 if I remember correctly.
Future builds will probably use the new Intel icc compiler (9.1), as it gives slightly faster code than anything I've seen so far from any gcc.
BM
BM
RE: Hello, i'm new here
)
Hey Crunch3r,
Welcome aboard the good ship Einstein!! I'm really pleased to see you participating here!!
I've been a long time user of your optimised Seti apps and am currently very pleased with the extra performance of your 5.12 over the standard app. Without hijacking this thread, I'd just like to say thanks for your work.
Cheers,
Cheers,
Gary.
RE: Future builds will
)
Thanks for the info, you should consider testing icc 9.0 first. From my point of view
(building S@H apps.) it genrates sometimes faster code.
Using icc myself on windows&linux i also noticed that icc 9.1 compiled code is sometimes 3x the size of icc 9.0 build binaries.
Until now i don't have a clue to that myself.
Thanks Gary.
Bad news is that ther'e won't be any optimized S@H app. any more.
But that's nothing that belongs here.
RE: i'm new here and
)
Hiya Crunch3r! Welcome aboard!
me-[at]-rescam.org
RE: RE: i'm new here and
)
RE: Using icc myself on
)
Have you looked at the binary itself with a hex editor or similar? It might be that different code and/or data alignment causes that, or, if you let the icc build code for different CPUs (-ax switch) the 9.1 distinguishes more platforms or inserts CPU switches in more places than the 9.0 does. Do you link glibc or Intel libs? The libraries might make a difference, too.
Last time I tried the icc 9.0 for Einstein@Home it didn't work at all, i.e. the linking failed. It also didn't vectorize the loop that I meant to. The code, however, has changed a bit since then, it might be worth another try now. Thanks for the hint.
BM
BM
RE: RE: Using icc myself
)
Hi Bernd,
the latests tests using icc on linux (at least for the S@H app.) showed that using intels cxx-lib (-cxxlib-icc) gives worse performance than using glibc, at least on 32bit linux on 64bit it's the other way around.
Have you tried forcing vectorization ?
There are some pragmas you can use in the code to force vectorization of loops.
RE: Hello, i'm new here
)
Welcome, crunch3r
Hope to see you ply your skills here.
Running 'nix 4.58 on several dual and dual-dual opterons with excellent luck so far.
again, welcome.