What compilers are used for Einstein@Home app?

michael37
michael37
Joined: 12 Aug 07
Posts: 12
Credit: 42,056
RAC: 0
Topic 193063

I've heard that Microsoft Visual Studio is used for Windows applications, but what compiler is used for Linux application?

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,522
Credit: 735,008,502
RAC: 1,292,335

What compilers are used for Einstein@Home app?

Quote:

I've heard that Microsoft Visual Studio is used for Windows applications, but what compiler is used for Linux application?

Not surprisingly, gcc , see this message from Bernd. Not sure which version, tho.

Bernd mentioned somewhere (can't find the thread now) that the goal was/is to compile all apps under gcc, but there are/were difficulties with getting one part of the app linked under gcc on Win (I believe it was the BOINC stuff).

CU

BRM

CU

BRM

michael37
michael37
Joined: 12 Aug 07
Posts: 12
Credit: 42,056
RAC: 0

Have developers considered

Have developers considered Intel compilers? For Linux, Intel has a very attractive non-commercial license (which may or may not be applicable for this project, depending on how grants cover effort of the developers), but even academic license is quite affordable.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 0

the intel compiler has a

the intel compiler has a major 'bug' that results in code executing very poorly on mad systems. Scare quotes are because intel is normally very quick in fixing bugs and has left this one untouched while fixing lots of more recent stuff.

And the dev team does test under a bunch of compilers to see which ones turn out the fastest code.

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

RE: the intel compiler has

Message 71589 in response to message 71588

Quote:

the intel compiler has a major 'bug' that results in code executing very poorly on mad systems. Scare quotes are because intel is normally very quick in fixing bugs and has left this one untouched while fixing lots of more recent stuff.

And the dev team does test under a bunch of compilers to see which ones turn out the fastest code.

I have to agree with you that it's not a bug, but the reason is not as sinister as people like to think. It's merely that Intel feels it's not under any obligation to test a commercial Intel product, designed for Intel products for any of it's competitors products, and thus cannot guarantee it's performance on non-Intel products. Therefore they disable certain features.

That rationale may not hold water technically, but does legally, and I wouldn't expect Intel to do anything about it anytime soon. ;-)

OTOH, AMD does recommend development products which supposedly do take full advantage of their processors capabilities, so if you know what you're doing and are diehard AMD, you should be able to workaround the 'problem' in a number of ways. :-)

Alinator

ohiomike
ohiomike
Joined: 4 Nov 06
Posts: 80
Credit: 6,453,639
RAC: 0

RE: RE: the intel

Message 71590 in response to message 71589

Quote:
Quote:

the intel compiler has a major 'bug' that results in code executing very poorly on mad systems. Scare quotes are because intel is normally very quick in fixing bugs and has left this one untouched while fixing lots of more recent stuff.

And the dev team does test under a bunch of compilers to see which ones turn out the fastest code.

I have to agree with you that it's not a bug, but the reason is not as sinister as people like to think. It's merely that Intel feels it's not under any obligation to test a commercial Intel product, designed for Intel products for any of it's competitors products, and thus cannot guarantee it's performance on non-Intel products. Therefore they disable certain features.

That rationale may not hold water technically, but does legally, and I wouldn't expect Intel to do anything about it anytime soon. ;-)

OTOH, AMD does recommend development products which supposedly do take full advantage of their processors capabilities, so if you know what you're doing and are diehard AMD, you should be able to workaround the 'problem' in a number of ways. :-)

Alinator


The AMD "bug" applies only to SSE3, SSE2 runs fine. I don't know if the app uses SSE3, but if it does not, the Intel code runs about 40-50% faster than GNU or Microsoft (even on AMD machines).


ohiomike
ohiomike
Joined: 4 Nov 06
Posts: 80
Credit: 6,453,639
RAC: 0

RE: RE: RE: the intel

Message 71591 in response to message 71590

Quote:
Quote:
Quote:

the intel compiler has a major 'bug' that results in code executing very poorly on mad systems. Scare quotes are because intel is normally very quick in fixing bugs and has left this one untouched while fixing lots of more recent stuff.

And the dev team does test under a bunch of compilers to see which ones turn out the fastest code.

I have to agree with you that it's not a bug, but the reason is not as sinister as people like to think. It's merely that Intel feels it's not under any obligation to test a commercial Intel product, designed for Intel products for any of it's competitors products, and thus cannot guarantee it's performance on non-Intel products. Therefore they disable certain features.

That rationale may not hold water technically, but does legally, and I wouldn't expect Intel to do anything about it anytime soon. ;-)

OTOH, AMD does recommend development products which supposedly do take full advantage of their processors capabilities, so if you know what you're doing and are diehard AMD, you should be able to workaround the 'problem' in a number of ways. :-)

Alinator


The AMD "bug" applies only to SSE3, SSE2 runs fine. I don't know if the app uses SSE3, but if it does not, the Intel code runs about 40-50% faster than GNU or Microsoft (even on AMD machines). It also "plugs into" Visual Studio, so the Windows code doesn't change at all, VS just uses ICC + IPP.



Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,522
Credit: 735,008,502
RAC: 1,292,335

RE: The AMD "bug" applies

Message 71592 in response to message 71590

Quote:


The AMD "bug" applies only to SSE3, SSE2 runs fine. I don't know if the app uses SSE3, but if it does not, the Intel code runs about 40-50% faster than GNU or Microsoft (even on AMD machines).

As far as I understand it, the ultimate goal is to have the hot-loop hand-optimized (either by hand-crafted assembly code or by coercing the gcc compiler in the right direction so that it generates highly optimized code e.g. by auto-vectorization. So basically the hot-loop should be "near-optimal" even with gcc someday, and the rest of the code will not have enough share on the overall runtime to cause that much of a speed-up even if it runs 50% faster.

Anyway, remember the cross-platform validation problem? It turned out to be caused by very subtle differences in code generation between the compilers, and was very hard to find. I'm not sure the dev team wants to open this can of worms again right now by switching the compiler (which can't be the universal compiler for the project since non-x86 platforms like PPC and later Sparc, etc, are supposed to be supported in the end). Of course there's no guarantee that gcc won't have any subtle differences between platforms, but using the same compiler "brand" should at least reduce the risk somewhat.

CU

BRM

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,312
Credit: 250,710,015
RAC: 35,718

Currently we are using

Currently we are using Microsoft Visual C++ compiler (7.1, workig on getting the code ready for 8.0) for Windows, mainly because BOINC mol. requires it. For all other platforms we're currently using gcc (Apples version of 4.0.1 on MacOS, for Linux we compile with gcc-4.1.2 and link with gcc-3.0 for compatibility).

I would be happy to use the Intel compilers for all platforms based on x86 CPUs, even if that involves patching the binaries to get the speed advantage to AMD CPUs. One of the reasons is that it uses the Intel syntax for Assembler (the "AT&T"-syntax of gcc really sucks for writing by hand), another one would be to only have to focus on a single compiler.

However the current code was originally developed on gcc, because it's the compiler best known and understood by the developers. As long as we're still fixing bugs and cross-platform problems I don't dare to possibly introduce more of them by switchig compilers now.

And I couldn't get our current code to build with the Intel compiler not even on MacOS, which usually is the least problematic platform. Getting this to work would require modifications to the code and build scripts that I don't want to make right now.

BM

BM

ohiomike
ohiomike
Joined: 4 Nov 06
Posts: 80
Credit: 6,453,639
RAC: 0

RE: Currently we are using

Message 71594 in response to message 71593

Quote:

Currently we are using Microsoft Visual C++ compiler (7.1, workig on getting the code ready for 8.0) for Windows, mainly because BOINC mol. requires it. For all other platforms we're currently using gcc (Apples version of 4.0.1 on MacOS, for Linux we compile with gcc-4.1.2 and link with gcc-3.0 for compatibility).

I would be happy to use the Intel compilers for all platforms based on x86 CPUs, even if that involves patching the binaries to get the speed advantage to AMD CPUs. One of the reasons is that it uses the Intel syntax for Assembler (the "AT&T"-syntax of gcc really sucks for writing by hand), another one would be to only have to focus on a single compiler.

However the current code was originally developed on gcc, because it's the compiler best known and understood by the developers. As long as we're still fixing bugs and cross-platform problems I don't dare to possibly introduce more of them by switchig compilers now.

And I couldn't get our current code to build with the Intel compiler not even on MacOS, which usually is the least problematic platform. Getting this to work would require modifications to the code and build scripts that I don't want to make right now.

BM


A good, concise answer. Thank you.


michael37
michael37
Joined: 12 Aug 07
Posts: 12
Credit: 42,056
RAC: 0

RE: Currently we are using

Message 71595 in response to message 71593

Quote:

Currently we are using Microsoft Visual C++ compiler (7.1, workig on getting the code ready for 8.0) for Windows, mainly because BOINC mol. requires it. For all other platforms we're currently using gcc (Apples version of 4.0.1 on MacOS, for Linux we compile with gcc-4.1.2 and link with gcc-3.0 for compatibility).

I would be happy to use the Intel compilers for all platforms based on x86 CPUs, even if that involves patching the binaries to get the speed advantage to AMD CPUs. One of the reasons is that it uses the Intel syntax for Assembler (the "AT&T"-syntax of gcc really sucks for writing by hand), another one would be to only have to focus on a single compiler.

However the current code was originally developed on gcc, because it's the compiler best known and understood by the developers. As long as we're still fixing bugs and cross-platform problems I don't dare to possibly introduce more of them by switchig compilers now.

And I couldn't get our current code to build with the Intel compiler not even on MacOS, which usually is the least problematic platform. Getting this to work would require modifications to the code and build scripts that I don't want to make right now.

BM

Thank you for your reply. Would you consider making the Einstein@Home application open source so other developers can take a stab at it?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.