REPORT WU-SPEEDS HERE !

>
> This still seems odd though. Because if the code is well-written, it should
> perform roughly the same as it does on windows, since both programs are
> basically spending most of their time doing Floating Point calculations, which
> is a CPU problem not a compiler problem.
>
I checked the GCC compiler manual about this; There a several compiler flags available for FPC, with no flags set you will loose speed for sure.

> The only thing is though, for windows to work on different archs, there is no
> way it can be optimized for an athlon-xp or penitum4 either.

I have no indept knowledge about windows/intel but could imagine a mechanisme that at installation time code and Libs are just better selected and matched to the specific arch then is done with "general" linux distro's as most of the people run.
Further more the tight relation between Microsoft and Intel might have given them an advantage anyhow ??

Any specialist out here ??

> This still seems odd though. Because if the code is well-written, it should
> perform roughly the same as it does on windows, since both programs are
> basically spending most of their time doing Floating Point calculations, which
> is a CPU problem not a compiler problem.

Even the best-written code will turn into garbage if compiled with a poor compiler. Most of the calculations will be handled by code in the maths libraries so optimising those would provide the greatest improvement.

> Well when you compile with gcc you would think it would optimize as much as it
> can for the 686 arch. I realize none of us run that arch anymore, but at the
> same time, and therefore using the athlon-xp or pentium4 arch would give
> better FP results.
>
> The only thing is though, for windows to work on different archs, there is no
> way it can be optimized for an athlon-xp or penitum4 either.

What you are forgetting is that those are only sub-categories of the x86 architecture. GCC is designed to produce code for PowerPC, Sparc, etc., etc.....

There are also trade-offs to consider. Sometimes, optimising for speed will produce larger executables - not always desireable. The default optimisations in GCC are a reasonable compromise to ensure stable executeables of acceptable size and with acceptable speed in most situations. It is the programmers prerogative to adjust those compromises for a given situation. A rich set of compiler flags is available for that purpose.

However, as I touched upon previously, another factor is the optimisation of the library routines with which the executable is linked. Linking can be done either statically or dynamically.

With dynamic linking, library routines are provided by the end-users system and loaded into memory as and when required and so the programmer has no control over them. The advantages of dynamic linking are a smaller executable and bug-fixes/enhancements to the libraries will automatically be available to the executable. It does mean, though, that the end-user will often need to have a particular version of the libraries available.

With static linking, the library routines are built in to the executable at compile time. This does produce much larger executables and requires a re-compile if anything changes in the libraries. In return, it gives the programmer more control over the end result and removes any dependancy requirements on the end-users system.

To achieve optimum performance in the Einstein app, it would be necessary to re-compile the libraries used with optimisation for each of the platforms supported and to also compile the app with similar optimisations and then to link statically. Finding the best optimisations for each supported architecture could, in itself, take a great deal of time and experimentation.

Releasing the source code would allow users to do this experimentation and produce optimised apps for a number of architectures as has been the case with the BOINC client. In fact, I always compile my own BOINC client and will, when I get around to it, have another go at the SETI app. My earlier attempts failed to get that to compile at all due to errors in the source code tarball.

Intel Prescott 3.2GHz HT on. 1GB PC3200 RAM. Running XP SP2.
Benchmarks using BOINC Manager V4.24 (real benchmarking)
Measured floating point speed 1339.55 million ops/sec
Measured integer speed 1709.98 million ops/sec

Einstein WU's take between 38,000 and 42,000 seconds each.
LHC million rotation WU's 45,000 to 47,000 seconds
Protein Pred 5,700 to 8,000 seconds
Seti 8,000 to 16,000 seconds
Climate 2.5 to 2.8 sec /time step