IPB

Welcome Guest ( Log In | Register )

> Hydrogenaudio Forum Rules

- No Warez. This includes warez links, cracks and/or requests for help in getting illegal software or copyrighted music tracks!
- No Spamming or Trolling on the boards, this includes useless posts, trying to only increase post count or trying to deliberately create a flame war.
- No Hateful or Disrespectful posts. This includes: bashing, name-calling or insults directed at a board member.
- Click here for complete Hydrogenaudio Terms of Service

 
Reply to this topicStart new topic
Intel's compiler and non-Intel processors, fact or fiction?, Split from: "Ogg Vorbis acceleration project"
forart.eu
post Jan 4 2010, 10:05
Post #1





Group: Members
Posts: 74
Joined: 10-December 09
From: italy
Member No.: 75798



Quite OT:

QUOTE
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.


Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jan 4 2010, 10:23
Post #2





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



Not only OT, but sounds very much like typical conspiracy theory. If you want your code to be well optimized for AMD processors, why on earth would you use Intel compiler in the first place? I'd be grateful that it supports AMD processors at all.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
sld
post Jan 4 2010, 12:20
Post #3





Group: Members
Posts: 1017
Joined: 4-March 03
From: Singapore
Member No.: 5312



It isn't a conspiracy theory if you had bothered to follow the link and performed a series of small Google searches on your own. The fact is that the Intel compiler almost always compiles better than Microsoft's. After the offending CPU check was bypassed, the AMD processors received a nice speed-up.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jan 4 2010, 12:46
Post #4





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



If i didn't follow the link i wouldn't comment on it, would i? There was no evidence presented in favor of this alleged conspiracy. So Intel is basically guilty of creating too good a compiler for their own processors? Lol.

This post has been edited by Gregory S. Chudov: Jan 4 2010, 13:03


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
skamp
post Jan 4 2010, 13:13
Post #5





Group: Developer
Posts: 1453
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (Gregory S. Chudov @ Jan 4 2010, 12:46) *
If i didn't follow the link i wouldn't comment on it, would i? There was no evidence presented in favor of this alleged conspiracy.

How about this one?

Hopefully that kind of crap won't happen with future iterations of ICC, now that Intel has settled with AMD and agreed not to engage in any anti-competitive behavior (you know, the kind they never engaged in in the first place, but made them sign a big fat check to AMD anyway).


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jan 4 2010, 13:39
Post #6





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



For starters, It has nothing to do with Intel Compiler. It comes down to
QUOTE
None of this constitutes proof of wrongdoing, but it flies in the face of Futuremark's neutrality claims.
.

You want good optimization for AMD's processors - ask AMD to make a compiler.

There's really no point for us to take part in wars between PR and legal departments of Intel, AMD and VIA. I honestly don't care about those fat checks they sign to each other. I prefer to stay neutral in these matters. I just don't like unproven conspiracy theories.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
skamp
post Jan 4 2010, 15:03
Post #7





Group: Developer
Posts: 1453
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE
None of this constitutes proof of wrongdoing, but it flies in the face of Futuremark's neutrality claims.

I'm not a conspiracy nut, so I didn't dig deep into it. The tests are pretty damning though. And even if ICC is not the culprit there, but FutureMark's code, why would they favor Intel CPUs if Intel didn't give them incentive to?

QUOTE (Gregory S. Chudov @ Jan 4 2010, 13:39) *
You want good optimization for AMD's processors - ask AMD to make a compiler.

They do contribute to GCC, offer optimized libraries for download, and there are at least two highly-optimized compilers for AMD CPUs (PGI and PathScale, IIRC). Do you, as a developer, bother to use them?

QUOTE (Gregory S. Chudov @ Jan 4 2010, 13:39) *
I just don't like unproven conspiracy theories.

But you like to ignore evidence of something fishy going on?


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jan 4 2010, 16:39
Post #8





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



I wouldn't ignore evidence if there was any.

The tests in fact only show that FutureMark doesn't handle VIA processors too good, and that VIA processors are closer to Intel than to AMD. Of course it could be because of Intel, but it could be due to alien invasion as well. The simplest explanation however is that FutureMark's programmers didn't do a very good job.

Personally i, as a developer, now prefer writing processor independent code, using Microsoft .NET framework. It's slightly slower than explicitly optimized code for a given platform, but i don't have to recompile it for every platform and i can be sure it will work more or less efficient on each of them. So it's now up to Microsoft and Mono developers to make sure .NET JIT compiler makes good code for various processors.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
skamp
post Jan 4 2010, 20:25
Post #9





Group: Developer
Posts: 1453
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (Gregory S. Chudov @ Jan 4 2010, 16:39) *
The simplest explanation however is that FutureMark's programmers didn't do a very good job.

Never ascribe to malice that which is adequately explained by incompetence, I know, but that would be a surprisingly big mistake, coming from guys who make a living on benchmarking. Too big in my opinion to ascribe it to incompetence.

QUOTE (Gregory S. Chudov @ Jan 4 2010, 16:39) *
So it's now up to Microsoft and Mono developers to make sure .NET JIT compiler makes good code for various processors.

(OT) Does FlaCuda run under Linux with Mono?


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
AshenTech
post Jan 4 2010, 22:23
Post #10





Group: Members
Posts: 79
Joined: 11-November 08
Member No.: 62144



heres a responce to those saying its a conspiricy theory

QUOTE
Intel Forced to Remove "Cripple AMD" Function from Compiler?
posted by Thom Holwerda on Sun 3rd Jan 2010 20:32 UTC
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.

Agner Fog details this particularly nasty examples of Intel's anticompetitive practices quite well. Intel's compiler can produce different versions of pieces of code, with each version being optimised for a specific processor and/or instruction set (SSE2, SSE3, etc.). The system detects which CPU it's running on and chooses the optimal code path accordingly; the CPU dispatcher, as it's called.

"However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string," Fog details, "If the vendor string says 'GenuineIntel' then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version."

It turns out that while this is known behaviour, few users of the Intel compiler actually seem to know about it. Intel does not advertise the compiler as being Intel-specific, so the company has no excuse for deliberately crippling performance on non-Intel machines.

"Many software developers think that the compiler is compatible with AMD processors, and in fact it is, but unbeknownst to the programmer it puts in a biased CPU dispatcher that chooses an inferior code path whenever it is running on a non-Intel processor," Fog writes, "If programmers knew this fact they would probably use another compiler. Who wants to sell a piece of software that doesn't work well on AMD processors?"

In fact, Fog points out that even benchmarking programs are affected by this, up to a point where benchmark results can differ greatly depending on how a processor identifies itself. Ars found out that by changing the CPUID of a VIA Nano processor to AuthenticAMD you could increase performance in PCMark 2005's memory subsystem test by 10% - changing it to GenuineIntel yields a 47.4% performance improvement! There's more on that here [print version - the regular one won't load for me].

In other words, this is a very serious problem. Luckily, though, it appears that the recent antitrust settlement between AMD and Intel will solve this problem for at least AMD users, as the agreement specifically states that Intel must fix its compiler, meaning they'll have to fix their CPU dispatcher.


The Federal Trade Commission is investigating Intel too, and it is also seeking a resolution of the compiler issue, but the FTC takes it all a step further than the Intel-AMD settlement. Since the latter only covers AMD, VIA could still be in trouble. Consequently, the FTC asks that Intel do a lot more than what's described in the AMD settlement:

QUOTE
Requiring that, with respect to those Intel customers that purchased from Intel a software compiler that had or has the design or effect of impairing the actual or apparent performance of microprocessors not manufactured by Intel ("Defective Compiler"), as described in the Complaint:


Intel provide them, at no additional charge, a substitute compiler that is not a Defective Compiler;

Intel compensate them for the cost of recompiling the software they had compiled on the Defective Compiler and of substituting, and distributing to their own customers, the recompiled software for software compiled on a Defective Compiler; and

Intel give public notice and warning, in a manner likely to be communicated to persons that have purchased software compiled on Defective Compilers purchased from Intel, of the possible need to replace that software.


Fog also offers up a number of workarounds, such as using GNU GCC, whose optimisations are similar to that of Intel's compiler, "but the Gnu function library (glibc) is inferior". You can also patch Intel's CPU dispatcher - Fog even provides a patch to do so in "Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms".

This is a particularly nasty kind of anticompetitive practice, as it really requires deep knowledge of matters in order to find it out. God knows how many benchmarks have been skewed in favour of Intel simply because people unknowingly used Intel's compiler in good faith. Intel's compiler is seen as the cream of the crop and delivers superior performance, but apparently only if you stick to GenuineIntel.


http://www.osnews.com/story/22683/Intel_Fo..._from_Compiler_

So yeah, Its a FACT and intel already agreed to stop doing it in their dealwith AMD, but the GOVT is going to requier them to be fair as well, so this is yet another layer of protection to help anybody whos not using an intel system insure they arent going to be artifically crippled.

Wonder if the x64 compile would be faster with the tricks to keep the intel compiler from crippling/hampering perf on amd cpus?

This post has been edited by AshenTech: Jan 4 2010, 22:26
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jan 5 2010, 06:02
Post #11





Group: Developer
Posts: 712
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (skamp @ Jan 4 2010, 22:25) *
(OT) Does FlaCuda run under Linux with Mono?

There's no reason why it shouldn't, however this was not tested. I use VMWare to test my software on linux, unfortunately there are no CUDA drivers for VMWare at this point.

QUOTE (AshenTech @ Jan 5 2010, 00:23) *
So yeah, Its a FACT and intel already agreed to stop doing it in their dealwith AMD, but the GOVT is going to requier them to be fair as well, so this is yet another layer of protection to help anybody whos not using an intel system insure they arent going to be artifically crippled.

There's too many twisted facts and unproven assumptions in this. For example, Intel didn't agree to stop doing anything, because it was never proven that they were doing it. Intel only promised never to do it in the future.

The most ridiculous unproven assumptions in those accusations are:
1) That benchmarks use Intel compiler generated code to test AMD and VIA processors
2) That Intel made them do it

Using Intel compiler generated code in benchmarks for all CPUs would not be fair, because it is certainly best optimized for GenuineIntel processors, and always will be.
On the other hand, using Intel compiler generated code for GenuineIntel processors and some other code for other processors can lead exactly to those test results which are presented as 'evidence': changing vendor id activates Intel code, which is faster.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Garf
post Jan 8 2010, 20:10
Post #12


Server Admin


Group: Admin
Posts: 4886
Joined: 24-September 01
Member No.: 13



QUOTE (Gregory S. Chudov @ Jan 4 2010, 13:39) *
There's really no point for us to take part in wars between PR and legal departments of Intel, AMD and VIA. I honestly don't care about those fat checks they sign to each other. I prefer to stay neutral in these matters. I just don't like unproven conspiracy theories.


First of all, it's not an unproven conspiracy theory. Anyone with the Intel compiler can check and see that the "GenuineIntel" detection code is there, and if it's disabled, programs magically run much faster on AMD systems.

As for "staying neutral", as a developer, you have to know about this, or your application will run slower for a large amount of your users, for no good reason at all. If you don't have AMD systems, you won't even know about it, but you might be hurt because, for example, a competing program may be faster because your binaries are crippled.

You can patch the produced binaries to disable the if-not-intel-use-slow-code detection and get good performance on all platforms.

The reason why it's an anti-competitive practice is exactly because the check is not checking for features, but for the manufacturer. It's also poor business practice to screw over your customers (the ones that buy the compiler) and it's particularly hazy that this "feature" was not documented anywhere.
Go to the top of the page
+Quote Post
AshenTech
post Oct 19 2012, 17:08
Post #13





Group: Members
Posts: 79
Joined: 11-November 08
Member No.: 62144



seems intel is still at it, this time blocking AVX from being useable on non-intel chips, (same links)

http://www.agner.org/optimize/blog/read.php?i=49

so, if you want AVX for amd chips dont use the intel compiler, theres no patch to remove the AVX blocking.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st December 2014 - 09:53