Intel Caught Cheating, Gets a Slap on the Wrist 14 Years Later

[patrickjp93]

I don't want compilers or links to software downloads, I want you to link to something that supports your opinions.  Why is that so hard to understand.

Excuse me but I claimed modern compilers still call on the CPUID string. If I provide you the source code showing this, that is support of my claim. What else would you like for my other claims since apparently you only accept specific evidence?

[mr moose]

Excuse me but I claimed modern compilers still call on the CPUID string. If I provide you the source code showing this, that is support of my claim. What else would you like for my other claims since apparently you only accept specific evidence?

 

Stop running back to an insignificant argument, you have claimed:

 

 

The lie is not that Intel didn;t optimize for AMD, it's that Intel was totally capable of doing so in the first place and was thus doing something illegal. BS!

 

and

 

 

It's hardly a nerf. Intel could not and cannot account for all of AMD's exotic instructions or tune a compiler for them without all specs related to them. If AMD provides that it essentially reveals their entire hand to their biggest competitor. All Intel can do is optimize based on the instructions AMD has licensed per chip from them. It's the same reason the Intel compiler beats Clang and GCC into the floor. Intel knows more about its own architecture than anyone.

 

and

 

 

 The FTC had no right to force Intel to change its proprietary compiler.

 

So far you haven't provided any evidence as to why they had no right, why you think the instructions being served to AMD cpus are the best available when I have linked to several authorities that have proven otherwise and nor have you even put up a decent explanation as to why the Intel compiler chose the instruction based on the Vendorid instead of the supported instructions it has already checked for (as claimed it does). 

 

I don't need to look at compiler code to know it checks the cpuid, What I want to see is evidence that what you are claiming is right.  I want to see someone other than your self make the same claims as you, I want to see you link to anyone of the thousands of tech websites, law firms, government agencies or employee blogs that supports your assertion that Intel did not nerf AMD cpus.  

 

In support of my claims I have linked to (either direct or indirectly):

 

number of articles cited: 4

Number of legitimate blogs: 1

Number of Government agencies: 1

 

So far the number you have linked:

 

Articles: 0

Government websites: 0

blogs: 0

company press releases:0

facebook pages: 0

diaries from 14 year old girls: 0

picture books of bulldozers: 0

instructions for lego city: 0

my little pony fansites: 0

 

 

links to download a compiler (not even the compiler in question mind you): 2

 

 

Now here is the most important bit, can you please prove that this is not true:

 

 

The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. 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.

 

[patrickjp93]

Stop running back to an insignificant argument, you have claimed:

 

 

 

and

 

 

 

and

 

 

 

So far you haven't provided any evidence as to why they had no right, why you think the instructions being served to AMD cpus are the best available when I have linked to several authorities that have proven otherwise and nor have you even put up a decent explanation as to why the Intel compiler chose the instruction based on the Vendorid instead of the supported instructions it has already checked for (as claimed it does). 

 

I don't need to look at compiler code to know it checks the cpuid, What I want to see is evidence that what you are claiming is right.  I want to see someone other than your self make the same claims as you, I want to see you link to anyone of the thousands of tech websites, law firms, government agencies or employee blogs that supports your assertion that Intel did not nerf AMD cpus.  

 

In support of my claims I have linked to (either direct or indirectly):

 

number of articles cited: 4

Number of legitimate blogs: 1

Number of Government agencies: 1

 

So far the number you have linked:

 

Articles: 0

Government websites: 0

blogs: 0

company press releases:0

facebook pages: 0

diaries from 14 year old girls: 0

picture books of bulldozers: 0

instructions for lego city: 0

my little pony fansites: 0

 

 

links to download a compiler (not even the compiler in question mind you): 2

 

 

Now here is the most important bit, can you please prove that this is not true:

The first 2 claims are one in the same, and they're based on rational thought and the fact Intel could not possibly try to optimize for AMD instructions since it didn't know the clock counts nor how the Out Of Order Processor was implemented (how to tile non-conflicting instructions). That's just common sense. How would you build a compiler for ARM if you didn't know what instructions were available and how many clocks each one took? You couldn't. It's a simple inductive proof.

 

I provided you the source code to modern compilers which still use the same technique and are the hallmarks of open source compiling. If you want the source code to the Intel compilers it would be illegal for me to publish it, and you can get your hands on it if you still use your university or high school email. Just get a student edition on a linux machine. It's a simple process for anyone to verify that Intel still uses this technique, but it would be illegal of me to publish the code as that's a violation of copyright. I have given you exactly the method to verify it for yourself, and it's a simple task.

 

Also, the claim of slowest possible code is complete BS. It's an opinion, and it completely ignores the fact Intel released its compiler for compatibility, not for robustness, with AMD's architecture. It could only guarantee the existence of instructions AMD had bought licenses to and were known to have been implemented on some series of chips. Beyond that compiling for AMD's architecture was a total black box until they publically released the documentation back in 2006, and this way predates that. This is just common sense and widely-known knowledge. 

 

If compatibility ends up being slow, too damn bad for AMD. Intel properly represented its own products while allowing people to compile for AMD architecture under the premise it couldn't guarantee peak performance without AMD's cooperation. If anyone assumed differently, that was their stupidity. I don't know what more you want. I'm as much an expert on compilers and what's possible as the same editors who wrote up the scandal pieces back in the day, and I've actually written a C++ compiler for ARM. There was no proof it was the slowest possible code, only that it was slow code which could be guaranteed to run. It would have been worse if Intel had optimized beyond what was possible and generated code which would crash on an AMD chip.

 

I never claimed Intel provided the best instructions possible for AMD architecture. My entire premise is that was impossible to ask for at the time when AMD's own instruction set wasn't even publically viewable. It had its own compiler which developers used when making programs for both companies' chips. Intel provided the only compatibility which could be promised.

 

Furthermore, Intel still does this, for exactly the reasons I have quoted, this by another enthusiast who actually went to the effort to decompile the code. http://www.agner.org/optimize/blog/read.php?i=49#49

 

You people can take pot shots at Intel all day, but the reality is this was in the era before AMD had even released the documentation of AM64 instructions. You can't optimize for code and instructions you aren't allowed to see. You can only use those which are guaranteed to you. In that sense the code will be inherently slower than what Intel could provide for its own architecture, but slowest possible? Absolutely no one has nor can prove that, because you can always insert more nops.

[flibberdipper]

Just saying, but this was on Techspot as well, so shut up people.

 

And second, my 1.7GHz P4 feels noticeably slower than my stepdad's Sempron 3000+ at the same speed as the P4.

[mr moose]

The first 2 claims are one in the same, and they're based on rational thought and the fact Intel could not possibly try to optimize for AMD instructions since it didn't know the clock counts nor how the Out Of Order Processor was implemented (how to tile non-conflicting instructions). That's just common sense. How would you build a compiler for ARM if you didn't know what instructions were available and how many clocks each one took? You couldn't. It's a simple inductive proof.

 

I provided you the source code to modern compilers which still use the same technique and are the hallmarks of open source compiling. If you want the source code to the Intel compilers it would be illegal for me to publish it, and you can get your hands on it if you still use your university or high school email. Just get a student edition on a linux machine. It's a simple process for anyone to verify that Intel still uses this technique, but it would be illegal of me to publish the code as that's a violation of copyright. I have given you exactly the method to verify it for yourself, and it's a simple task.

 

Also, the claim of slowest possible code is complete BS. It's an opinion, and it completely ignores the fact Intel released its compiler for compatibility, not for robustness, with AMD's architecture. It could only guarantee the existence of instructions AMD had bought licenses to and were known to have been implemented on some series of chips. Beyond that compiling for AMD's architecture was a total black box until they publically released the documentation back in 2006, and this way predates that. This is just common sense and widely-known knowledge. 

 

If compatibility ends up being slow, too damn bad for AMD. Intel properly represented its own products while allowing people to compile for AMD architecture under the premise it couldn't guarantee peak performance without AMD's cooperation. If anyone assumed differently, that was their stupidity. I don't know what more you want. I'm as much an expert on compilers and what's possible as the same editors who wrote up the scandal pieces back in the day, and I've actually written a C++ compiler for ARM. There was no proof it was the slowest possible code, only that it was slow code which could be guaranteed to run. It would have been worse if Intel had optimized beyond what was possible and generated code which would crash on an AMD chip.

 

I never claimed Intel provided the best instructions possible for AMD architecture. My entire premise is that was impossible to ask for at the time when AMD's own instruction set wasn't even publically viewable. It had its own compiler which developers used when making programs for both companies' chips. Intel provided the only compatibility which could be promised.

 

Furthermore, Intel still does this, for exactly the reasons I have quoted, this by another enthusiast who actually went to the effort to decompile the code. http://www.agner.org/optimize/blog/read.php?i=49#49

 

You people can take pot shots at Intel all day, but the reality is this was in the era before AMD had even released the documentation of AM64 instructions. You can't optimize for code and instructions you aren't allowed to see. You can only use those which are guaranteed to you. In that sense the code will be inherently slower than what Intel could provide for its own architecture, but slowest possible? Absolutely no one has nor can prove that, because you can always insert more nops.

 

Still nothing I see,  when you work out the difference between a compiler and a supporting document/article come back and make your case.  At the moment you are just going around in circles making claims that aren't backed by anything.

[patrickjp93]

Still nothing I see,  when you work out the difference between a compiler and a supporting document/article come back and make your case.  At the moment you are just going around in circles making claims that aren't backed by anything.

I provided you a support blog that is more than legitimate. He's been hosting advanced coding tutorials for years and actually knows how to test and get at the meat of them, like me. Read the damn page. Second, why bother with a support page which lies/can lie when you can go in and verify the results yourself as I have? What is it about tertiary sources you seem to like? It's not like the FTC sued on proof of wrongdoing.

[mr moose]

I provided you a support blog that is more than legitimate. He's been hosting advanced coding tutorials for years and actually knows how to test and get at the meat of them, like me. Read the damn page. Second, why bother with a support page which lies/can lie when you can go in and verify the results yourself as I have? What is it about tertiary sources you seem to like? It's not like the FTC sued on proof of wrongdoing.

 

You provided the same blog that I did, I guess you didn't read it.

 

I like sources that qualify their research, I like sources that are peer reviewed, I like source that have in depth statistical support. I don't consider being told to de-compile a piece of software as evidence against something that has already been proven by others with better knowledge and significantly more experience than me.

 

From the link you provided:

 

 

I have complained about this behavior for years, and so have many others, but Intel have refused to change their CPU dispatcher. If Intel had advertised their compiler as compatible with Intel processors only, then there would probably be no complaints. The problem is that they are trying to hide what they are doing. 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

 

 

 

This is basically the same statement I quoted 2 pages ago from Agner where he claims the compiler intentionally chooses an inferior code. Can you please either accept you are wrong or provide something to support your claims that this isn't true.

[ViruZ_HUN]

i think Linus bashed it once and now everyone does. pretty much whatever Linus says people will blindly follow here.

Yeah. Linus is a great guy, But not everyone needs to be Linuses and think just as him

[patrickjp93]

You provided the same blog that I did, I guess you didn't read it.

 

I like sources that qualify their research, I like sources that are peer reviewed, I like source that have in depth statistical support. I don't consider being told to de-compile a piece of software as evidence against something that has already been proven by others with better knowledge and significantly more experience than me.

 

From the link you provided:

 

 

 

This is basically the same statement I quoted 2 pages ago from Agner where he claims the compiler intentionally chooses an inferior code. Can you please either accept you are wrong or provide something to support your claims that this isn't true.

I'm not wrong. The dispatcher checks the CPUID string just as I've been saying. All of the big compilers do this. Each chip family does something better, which is why each family and each brand is optimized for individually. I never claimed Intel stopped doing that. They do it still and it's legal! It's also fair and necessary. What he provides in his blog is careless agnosticism which still favors Intel chips but doesn't unlock the full potential of other brands. And he can't because no one is that familiar with AMD arch. apart from AMD.

[yoloswag9000]

I'm not wrong. The dispatcher checks the CPUID string just as I've been saying. All of the big compilers do this. Each chip family does something better, which is why each family and each brand is optimized for individually. I never claimed Intel stopped doing that. They do it still and it's legal! It's also fair and necessary. What he provides in his blog is careless agnosticism which still favors Intel chips but doesn't unlock the full potential of other brands. And he can't because no one is that familiar with AMD arch. apart from AMD.

Normal compilers don't create a "dispatcher" for you.

[patrickjp93]

Normal compilers don't create a "dispatcher" for you.

Oh yes they do. Feel free to browse the source code of GCC.

[yoloswag9000]

Oh yes they do. Feel free to browse the source code of GCC.

How about you show me the code segment? You're the one claiming it is in there, after all.

[patrickjp93]

How about you show me the code segment? You're the one claiming it is in there, after all.

Must I really do everything for you people? How did you survive college/university?

 

https://gcc.gnu.org/wiki/FunctionMultiVersioning 

 

To create an executable which is architecture agnostic where possible.

[mr moose]

I'm not wrong. The dispatcher checks the CPUID string just as I've been saying. All of the big compilers do this. Each chip family does something better, which is why each family and each brand is optimized for individually. I never claimed Intel stopped doing that. They do it still and it's legal! It's also fair and necessary. What he provides in his blog is careless agnosticism which still favors Intel chips but doesn't unlock the full potential of other brands. And he can't because no one is that familiar with AMD arch. apart from AMD.

 

You are, you claim Intel didn't nerf AMD cpus in their compiler, you are claiming the quotes and articles I posted are wrong, yet you haven't posted anything to support this.

 

Address the claims at hand and stop going back to moot arguments.  No one cares if today's compilers check cpuid, this has been stated over and over again and has nothing to do with the claims so stop talking about it and address the actually claims made by AMD, by Agner, by the FTC and by swallowtail. 

 

 

 

Must I really do everything for you people? How did you survive college/university?

 

So far you haven't done anything for anyone except ramble on and try to claim everyone is wrong but you.

[MonkeyFace]

$15? Thanks for the haircut intel

[yoloswag9000]

Must I really do everything for you people? How did you survive college/university?

 

https://gcc.gnu.org/wiki/FunctionMultiVersioning 

 

To create an executable which is architecture agnostic where possible.

Now if you stop insult people and always back your statements up like you did here, that'd be great. It would save us a day and 3 posts of noise.

 

Anyway, I don't have a problem with Intel having a compiler which outputs better code for Intel CPUs. It's stupid to have your own compiler instead of implementing the improvements in open source compilers and for me those vendor specific compilers just don't exist. You get a real problem, however, if a benchmark is compiled with unfair advantage for one vendor. Either use an open source compiler or use the best available compiler for every hardware you're testing.

[tobben]

$15? Thanks for the haircut intel

lol, the question i have is.

Is intel required to look up the people to repay them on own initiative?

or do people have to step up and claim it?

 

i doubt they are going to pay many people at the end of this..

It's something that happened more than 12 years ago.

[mr moose]

lol, the question i have is.

Is intel required to look up the people to repay them on own initiative?

or do people have to step up and claim it?

 

i doubt they are going to pay many people at the end of this..

It's something that happened more than 12 years ago.

 

Most of these cases end up ruling that people will have to claim, there will be a window in which you will have to have bought an Intel processor and you'll have to provide proof of purchase.  So I surmise Intel won't be paying out that much in the end.

[tobben]

Most of these cases end up ruling that people will have to claim, there will be a window in which you will have to have bought an Intel processor and you'll have to provide proof of purchase.  So I surmise Intel won't be paying out that much in the end.

heh, exactly. Borderline to nothing

i would definitely throw away or loose my receipt after 10+ years..

and i definitely wouldn't expend effort on claiming a few bucks.

 

Not to mention the entire case would likely bypass me entirely..

[mr moose]

heh, exactly. Borderline to nothing

i would definitely throw away or loose my receipt after 10+ years..

and i definitely wouldn't expend effort on claiming a few bucks.

 

Not to mention the entire case would likely bypass me entirely..

 

Funny thing is, in that time frame I bought 2 Intel processors, but they were for other people who probably didn't keep the receipts,  I brought an AMD cpu for me and I did keep the receipt.  

[EmmaLong]

AMD's still cheating...

http://www.geeks3d.com/20100916/fp16-demotion-a-trick-used-by-ati-to-boost-benchmark-score-says-nvidia/

 

How about you actually read the article from which you took that image . There's no foul play here. You're just biased.

AMD Statement :

"For our Southern Island product family launch we picked a set of

settings that we tested in several scenarios for image quality and found

that those specific settings were providing the best overall quality.

When you pointed out these issues in some games around texture quality,

we went back and found one specific setting that was causing the

described texture blurriness. This has now been removed and the quality

of textures should be as intended, with performance unchanged. These

settings will be adjusted accordingly in the 12.4 April Catalyst

release, later this month."

 

Tom's Hardware : "Despite the obviously higher image quality provided by the fixed driver,

resulting performance is almost identical and well within a margin of

error."

Here's the full article, don't be an idiot.

http://www.tomshardware.com/re...

[Slick]

Personally I just generally ignore all rumors until they are confirmed officially by whoever the rumor is about

 

I don't have anything SPECIFICALLY against WCCF tech personally - just not into rumors

 

@sTizzl Sorry about them, we value all members of our community regardless of post count - before having this job I was a forum lurker as well... This goes for everyone -> if you ever have problems with people please report them, I, and the forum moderation team, will try our hardest to keep the negative crap shoot that can sometimes be the internet off this website.

[patrickjp93]

You are, you claim Intel didn't nerf AMD cpus in their compiler, you are claiming the quotes and articles I posted are wrong, yet you haven't posted anything to support this.

Address the claims at hand and stop going back to moot arguments. No one cares if today's compilers check cpuid, this has been stated over and over again and has nothing to do with the claims so stop talking about it and address the actually claims made by AMD, by Agner, by the FTC and by swallowtail.

So far you haven't done anything for anyone except ramble on and try to claim everyone is wrong but you.

I have proven you wrong by strong inductive reasoning and use of absolute facts. If you fail to recognize this then I worry for those you mentor, but enough. The thread's been derailed and the politics of this will poison others.

[patrickjp93]

Now if you stop insult people and always back your statements up like you did here, that'd be great. It would save us a day and 3 posts of noise.

Anyway, I don't have a problem with Intel having a compiler which outputs better code for Intel CPUs. It's stupid to have your own compiler instead of implementing the improvements in open source compilers and for me those vendor specific compilers just don't exist. You get a real problem, however, if a benchmark is compiled with unfair advantage for one vendor. Either use an open source compiler or use the best available compiler for every hardware you're testing.

I have every right and reason to insult you for being lazy. There's no free lunch. I was obligated to provide sources of code and I did. The fact you're requiring me to find you the exact lines is what pissed me off. If you're smart enough to understand the source, you will find it quite quickly. If you're not, chances are you won't understand the code I'd post directly. It's lose-lose for me all the damn time on this website because people are just so damn lazy.

Also, Intel makes $700 per sale of their compiler for a 1-year license. They make a ton of money off it. Microsoft sells Visual studio for up to $13,000 a pop on the big server/web/scientific development packages.

[awesomes8wc3]

how do i claim??

i have a pc from 2001 with a p4 so i want my 15 dallas