CPUs/Compilers for Numerical Simulations?

X43B asks: "I'm building a 'luggable' computer for numerical simulation work (very niche, I know). My goal is to have the best single precision floating point performance for under $1000. I have decided on a Shuttle XPC layout. I can build a AMD 3500+ for ~$80 less than a Prescott 3.4Ghz. I know the AMD is supposed to be a better 'general purpose' CPU however I found this comparison which says the Intels are better for floating point. Additionally, even though the AMD is somewhat cheaper, I have found the free Intel Linux FORTRAN compiler quicker than gfortran. So even if the AMD had similar performance for cross compiling, the Intel would be ~10% faster with the free compiler. Does anyone have any recommendations on AMD vs Intel for single precision floating point operations? If you recommend the AMD, what (cheap or free) compiler can be used that is comparable to the Intel?"

Comments

$80?

[jeffy124]

Try thinking this through in terms of return-on-investment. If $80 is all you're going to save on a product that's around $1000, it may not be worth it, especially given what else you know is going into each product. First, it's an 8% savings, hardly a significant bargain. Second, from what it sounds like you'll be doing with it, $80 extra for an Intel chip is very small sum for the increased performance (10% from your description above) you'll be getting in return. Third, assume you do find similar performance for an AMD, but might require payment for a compiler negating the $80 savings. Finally, ask yourself if searching for a free (as in beer) AMD compiler is worth $80 of your time if you already have everything in place for an Intel.

I think you're best bet is the little extra you spend for the Prescott model.

save the money for tools

[ghostlibrary]

Save your CPU money for the compiler (e.g. PGF90, or what have you), or for development tools, and for more RAM. A good compiler will give you a better handle on numerical accuracy than a 'better' CPU stuck with an off compiler. More RAM will keep you from being stingy in single/double precision allocations.

Also, factor in your work time. A few percentage difference between CPUs won't count nearly as much as the 2 hours you saved because you had a good debugger, or the 4 hours saved because your editor makes it easier to write and jump around your code.

Your accuracy will be pretty much the same, you just have to understand how computers represent floats and plan accordingly. Use accurate representations even if they're slower to get the numerical accuracy you need, then optimize the slow parts.

Only optimize the stuff that runs slow. That means profile, don't just guess. You'll often be surprised by where the bottlenecks are.

Higher accuracy usually means more memory (going with doubles rather than floats) or work (converting to integers within your desired floating range to control floating point accuracy). CPU won't be a biggie, but having lots of RAM will help.

If you have a choice between spending 3 months writing and optimizing code, or spending 1 month writing code that isn't optimized, think of what 2 months of runtime will do. If it takes you a while to write the code, just buy your super-accurate machine _after_ coding, when it's time to do your real runs (since chip speeds already increase).

In fact, if it takes you 3 months to optimize, you'd be better off keeping the slow code, doing another project, and 3 months later just buying a faster PC to run the slow old code :)

All this off the top of my head, hope it helps.

Re:save the money for tools

[samael]

Writing efficient code is great - if what you want to end up with at the end is some really efficient code.

If what you want is....results, then efficient code is one of many ways of getting it, and not necessarily the most efficient one.

Re:there is a difference

[cperciva]

No FPU meeting this standard [IEEE 754] will produce different results than any other FPU.

Correct as far as arithmetic operations go, but not for other functions. Trigonometric functions are quite a different story, and the results will vary between processors -- older Intel (co-)processors were accurate to 4.5 ulp, whereas recent ones are accurate to 1.5 or 1.0 ulp, for example.

For that matter, as far as I'm aware IEEE 754 doesn't make *any* requirements of the trigonometric functions; they might behave as random number generators for all the standard says.

don't worry about it

[jeif1k]

I wouldn't start relying on special compilers; once you go down that road, you start putting processor-dependent features into your code, you start battling with compatibility issues, your code becomes less usable by others, and you have less choice in software from others that you can use; it all becomes a huge waste of time.

Instead, check for yourself which system (not processor, but system) gives you the most bang for the buck using the most standard compiler you can find. If you use gcc, I believe systems based on AMD's 64bit chips still win.

And, realistically, 10-20% differences are not worth investing a lot of time or energy in anyway; that corresponds to a few months of progress in processor and systems development.

Some interesting results

[rgbe]

I spent a summer benchmarking a couple of new computers for a the University of Otago Physics department. They were looking into buying a cluster for their Bose-Einstien condensate experiments, it was my job to see where things were going slow. I found the major bottleneck was in the network. But I also made comparisons between a P4 2.4GHz and AMD Athon-XP 2400+, the results are interesing.

No IEEE floats

[pkhuong]

GPUs don't do IEE floats. That might be bad for his purpose...