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

What compilers are used for Einstein@Home app?
)
Actually we're considering to publish the code every few months or so.
With the philosophy and implementation of the BOINC framework there is no way to ensure that a BOINC Core Client runs a specific program (or refuses to run self-built programs), so we currently have no other measurement to ensure that a certain version of the program is run than to keep the source mol. closed.
The ultimate goal would be to improve the validator so that results that are scientifically valid (and only those) would pass validation, regardless of the program that computed them. But at the moment with the new algorithm and the problems we're currently dealing with we are nowhere near this.
BM
BM
RE: I wonder what is the
)
It's right that with the new program we are still in the first "phase".
Some further remarks:
- With the concept of BOINC I think a suitable validator would need to be developed and running before the source code (i.e. all of it) is made public.
- Validation is always a tradeoff between time and security. The only way one could be really sure of a valid result (a "fool-proof validatior") would be to perform the same calculations on a controlled machine hidden to the public, and compare the results. Everything else is based on mol. reasonable assumptions that might fail in a particular case.
- A "stable scientific algorithm" is hard to achieve, because it's not only the algoritm that counts. Even compilers have bugs and flaws that could render a particular algorithm numerically unstable. I just had one such case where the Microsoft C++ compiler (7.1) ignored an explicite cast (probably for performance reasons).
BM
BM
RE: I'm intrigued by the
)
I'm tempted by the ideo of having an installer that choses an App version suitable for a specific computer. It's much easier to compile and optimize a whole App for a specific CPU than to have various places that detect CPU features and chose different code paths within the App.
As long as we're observing serious bugs in the App code, however, I don't dare to rely on Apps that have to be manually updated, as anonymous Apps are.
BM
BM