climateprediction.net home page
Posts by old_user73375

Posts by old_user73375

1) Questions and Answers : Windows : Bad Performance (Message 12309)
Posted 5 May 2005 by old_user73375
Post:
> > Carl,
> >
> > I don't know how much it might apply to this situation...and whether the
> > Fortran compiler has such switches, but something of an interesting read,
> with
> > a link, on the Intel compiler and AMD64 here...
> >
> > http://www.theinquirer.net/?article=14077
> >
> > and here
> >
> > http://www.theinquirer.net/?article=13821
> >
> > Like I said, it may not apply, and even so there is a lot to read off
> the
> > first articles link
> There looks like some great information from the google link off
> http://www.theinquirer.net/?article=14077; a snippet:
>
> **** Snippet Start ****
> I started mucking around with a dissassembly of the Intel-specific binary and
> found one particular call (proc_init_N) that appeared to be performing this
> check. As far as I can tell, this call is supposed to verify that the CPU
> supports SSE and SSE2 and it checks the CPUID to ensure that its an Intel
> processor. I wrote a quick utility which I call iccOut, to go through a binary
> that has been compiled with this Intel-only flag and remove that check.
>
> Once I ran the binary that was compiled with the Intel-specific flag (-QxN)
> through iccOut, it was able to run on the FX51. Much to my surprise, it ran
> fine and did not miscompare. On top of that, it got the same 22% performance
> boost that I saw on the Pentium4 with an actual Intel processor. This is very
> interesting to me, since it appears that in fact no Intel-specific
> optimization has been done if the AMD processor is also capable to taking
> advantage of these same optimizations. If I'm missing something, I'd love for
> someone to point it out for me. From the way it looks right now, it appears
> that Intel is simply "cheating" to make their processors look better against
> competitor's processors.
> **** Snippet End ****
>

Greetings,

I think the foregoing snippet quite clearly identified the problem with CPDN code compiled with the Intel Fortran Compiler and running on the AMD64 architecture: the programming SHOULD HAVE TREATED THE AMD64 IDENTICALLY with the Pentium processors -- all support the SSE2 instructions. The current BOINC CPDN programming erroneously TURNS OFF SSE2 optimizations for the AMD processors.

Yet, in reading through this thread, I see alot of unnecessary speculation about the reasons for the BOINC performance problems on the AMD (e.g. maybe the AMD procs don't have P4 optimizations, etc. etc.) -- when at the very beginning of the thread, the programming error is very clearly identified! It has nothing to do with differences between the AMD and Intel processors -- the code turns off optimizations for the AMD when the optimizations would work fine!

Could I ask when the bug identified in the snippet above will be fixed so that the massive waste of processing capacity (maybe 25% of all AMD horsepower available to CPDN) can be stopped? Or has this already been addressed?

Contrablue





©2024 climateprediction.net