Linked by Thom Holwerda on Sun 3rd Jan 2010 20:32 UTC
General Development Here's something you probably don't know, but really should - especially if you're a programmer, and especially especially if you're using Intel's compiler. It's a fact that's not widely known, but Intel's compiler deliberately and knowingly cripples performance for non-Intel (AMD/VIA) processors.
Thread beginning with comment 402311
To read all comments associated with this story, please click here.
jbettcher
Member since:
2008-06-15

The main people this bug bothers and has hindered:

People with AMD systems using the ICC compiler. (which would make me ask why)

Intel hasn't hindered AMD in anyway when it comes to the normal XP/Vista/7 user running an AMD system, different C compilers were used to generate their programs and optimizations have been put in place by other developers.

Sure this make Intel look like bastards for their tactics with their own compiler. But if this was some huge sabotage move like people are making it to be Intel would've been sued into oblivion by now.

Reply Score: 1

Thom_Holwerda Member since:
2005-06-29

Sure this make Intel look like bastards for their tactics with their own compiler. But if this was some huge sabotage move like people are making it to be Intel would've been sued into oblivion by now.


Uhm, they HAVE been sued into oblivion, and the compiler was part of said lawsuit between AMD and Intel (and now it's part of the settlement). It's also part of the FTC probe.

It's all in the articles. Didn't you read them?

Reply Parent Score: 1

cerbie Member since:
2006-01-02

"People with AMD systems using the ICC compiler. (which would make me ask why)"

...because nobody uses both Intel and AMD processors.

...because nobody uses binaries they did not personally compile.

Reply Parent Score: 3

setec_astronomy Member since:
2007-11-17

People with AMD systems using the ICC compiler. (which would make me ask why)


Just a little perspective, even though I'm aware it's a bit of an extreme data point:

About three years ago, small scale clusters (esp. capacity machines) employing AMD Opteron processors and Gigabit Ethernet were in full swing in the HPC community, beacause they offered a very nice bang for the 10k€ - 100k€ Buck. Nothing earthshattering and certainly not Top500 material, but - especially due to the integrated memory controller - very nice machines to do test- and development runs before blocking the production machines with unoptimised code. As a consequence, AMD was able to capture a lot of ground of what was traditionally Intels hometurf.

Despite AMDs inroads in the hardware department, a lot of scientists (e.g. the "end users" of the HPC facilities) still defaulted to the intel compiler suite, due to various reasons: For Linux and non-commercial use, the compiler is gratis (this does not cover academic use, but as far as I'm aware of virtually nobody gives a damn) and is not limited compared to the commerical option, which makes it a lot more attractive than for example the PGI suite or the NAG compilers. Additionally, or even because of that, even if you have to deploy your code on a different x86 based cluster system (for example for a "real" production run) odds are good that the intel compilers are available, widely used and therefore well maintained.

Combine this with the fact that bulk of scientific code in many disciplines (like for example lattice QCD) is still written using a wild mixture of Fortran 77/90 + properitary Compiler extensions and neither gcc nor g95 up until recently having competative fortran compilers and you have quite a big hurdle to move away from the intel compilers (some might even go as far as calling this a potential vendor lock-in, those obnoxious brats, tz tz tz).

The majority of scientists in "my" field (high energy physics) are more interested to actually "get the job done" (oh how I hate this phrase but once in a while it's really appropiate) and not to fiddle with optimisation options and processor specific behaviour.
Consequently, they and the folks that have to actually maintain these cluster systems tend to be a conservative bunch, so that the un-sexy work of fine-tuning and optimising the code for a given compiler has to be done ideally only once.

If turning on optimisation options for SSEx/vectorisation yields not the performance gains people expect or are even used to, the "new" component (aka the non-Intel hardware) tends to receive the blame and not the compiler ("scales as expected on my Xeon desktop workstation, sucks at your shitty SUN / Opteron cluster. Fix that") . And although this behaviour was discovered some time ago, you would be surprised how many "end users" of HPC facilities are not aware of the implications of this performance regressions.

As a side note: If you are a programmer and interested in the ins- and out of optimising code, make sure to check out the sotware optimisation ressources on Agner Fog's site, they are imho a classic read:

http://www.agner.org/optimize/

Reply Parent Score: 5

Scali Member since:
2010-01-03

Despite AMDs inroads in the hardware department, a lot of scientists (e.g. the "end users" of the HPC facilities) still defaulted to the intel compiler suite, due to various reasons: For Linux and non-commercial use, the compiler is gratis (this does not cover academic use, but as far as I'm aware of virtually nobody gives a damn) and is not limited compared to the commerical option, which makes it a lot more attractive than for example the PGI suite or the NAG compilers. Additionally, or even because of that, even if you have to deploy your code on a different x86 based cluster system (for example for a "real" production run) odds are good that the intel compilers are available, widely used and therefore well maintained. Combine this with the fact that bulk of scientific code in many disciplines (like for example lattice QCD) is still written using a wild mixture of Fortran 77/90 + properitary Compiler extensions and neither gcc nor g95 up until recently having competative fortran compilers and you have quite a big hurdle to move away from the intel compilers (some might even go as far as calling this a potential vendor lock-in, those obnoxious brats, tz tz tz).


It's not Intel's fault that AMD doesn't offer an alternative product.

By the way, the runtime selection of codepaths is just a compiler option.
It's perfectly possible to compile only a single codepath and effectively 'force' your CPU to run SSE/whatever code.
I've been using it on my Athlon back in the day, and got pretty good results.

Reply Parent Score: 1