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

[patrickjp93]

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/SOG_16h_52128_PUB_Rev1_1.pdf -> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AMD64_16h_InstrLatency_1.1.xlsx  ¯\_(ツ)_/¯

Having spent the time reading this, it isn't helpful for compiler development. There's not mention of which operations are atomics or which ones conflict with execution of others. There's nowhere near the amount of info a good compiler maker needs.

[patrickjp93]

Not the first or last of anything, It was always the case that Intel nerfed the compiler and the anti competitive behaviour with pc vendors is a separate incidence. Proof below.

There is plenty of information on it around the net, it's was not because they refused to account for "exotic" AMD instructions, the code actually looked at the vendor ID string and intentionally ran the slowest code for non Intel chips.

http://www.brightsideofnews.com/2009/12/17/why-the-ftc-lawsuit-against-intel-has-substance/

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

http://www.swallowtail.org/naughty-intel.shtml

http://www.osnews.com/story/22683/Intel_Forced_to_Remove_quot_Cripple_AMD_quot_Function_from_Compiler_

http://www.theinquirer.net/inquirer/news/1567108/intel-compiler-cripples-code-amd-via-chips

The FTC even forced Intel to change it:

It is a fact that the compiler intentionally crippled non Intel CPUs, this is not disputable but cold hard reality.

I really don't know nor understand why anyone would try to argue this didn't happen.

Now that is a blatant lie. It looked at the CPUID string and adjusted optimization settings to what was appropriate and available on a given architecture, and you could not find this AMD instruction set information online 10 years ago or even 5. The FTC had no right to force Intel to change its proprietary compiler. If AMD wanted the fastest code possible on Cinebench it would have provided its own compiler and allowed users to download Intel and AMD-tailored versions of Cinebench. Even today Intel still destroys AMD in Cinebench scores going back to 2009 chips.

[dalekphalm]

If you have hard evidence, the court will rule in your favor and the losing party has to pay all cost produced by the legal disupte plus whatever the court sees fitting for punishment/compensation. From a money perspective there is no reason not to sue if you have hard evidence. Except if the other party has something on you and will use it if you sue them but that stuff is basically unknown to us which makes everything about it speculative.

 

So, yes, I agree with you, what you can however say is that there is a good possiblity that AMD is generally not anti-competitive.

 

When we're simply looking at the hard facts we have you can clearly see a history anti-competitive, quasi-monopoly abusing behavior on Intels part (at least that's what the court said) and none of it on AMDs part. This is not hard evidence (what actually is? the definition of the word can be stretched and like most words are relative) that it actually was and/or is happening, it only shows that the courts in a few different countries thought so.

 

Another fact you have to consider is the market share, the sales and profits. This is not a joke, Intels net income is more than 21.000% more than AMDs (pretty interesting visualization on wolfram alpha http://www.wolframalpha.com/input/?i=amd+vs+intel+profit&lk=4&num=1). There is no freaking way that AMD is even maniging to do anything anti-competitive, they simply don't have the money to do that.

I definitely agree that in my opinion, AMD is basically on the level with all their business practices.

 

They really can't afford to get sued by Intel.

 

Also, facts and evidence don't necessarily mean anything in the US Court system. Just look at all the collective Samsung vs Apple lawsuits. And I'm not even talking about one vs the other. They've BOTH sued each other and in some cases WON when they shouldn't have (Although Apple does seem to get away with this a lot more often).

[patrickjp93]

If you have hard evidence, the court will rule in your favor and the losing party has to pay all cost produced by the legal disupte plus whatever the court sees fitting for punishment/compensation. From a money perspective there is no reason not to sue if you have hard evidence. Except if the other party has something on you and will use it if you sue them but that stuff is basically unknown to us which makes everything about it speculative.

 

So, yes, I agree with you, what you can however say is that there is a good possiblity that AMD is generally not anti-competitive.

 

When we're simply looking at the hard facts we have you can clearly see a history anti-competitive, quasi-monopoly abusing behavior on Intels part (at least that's what the court said) and none of it on AMDs part. This is not hard evidence (what actually is? the definition of the word can be stretched and like most words are relative) that it actually was and/or is happening, it only shows that the courts in a few different countries thought so.

 

Another fact you have to consider is the market share, the sales and profits. This is not a joke, Intels net income is more than 21.000% more than AMDs (pretty interesting visualization on wolfram alpha http://www.wolframalpha.com/input/?i=amd+vs+intel+profit&lk=4&num=1). There is no freaking way that AMD is even maniging to do anything anti-competitive, they simply don't have the money to do that.

AMD can't be anti-competitive? Are you joking? Apart from blatantly lying about processor specs from the core count to the instructions per clock, AMD also completely fudged benchmarks back in 06-7-8 too. It's not about the money. It's about the practices. Lastly, you seem to forget AMD and Nvidia have been caught price fixing as recently as last year while also fudging the GPU capabilities of Tegra and Mullins. AMD is as corrupt and anti-competitive as any of them given the opportunity.

[yoloswag9000]

I definitely agree that in my opinion, AMD is basically on the level with all their business practices.

 

They really can't afford to get sued by Intel.

I tried to understand the first sentence but I really can't, sorry. Can you please rephrase it?

Also, facts and evidence don't necessarily mean anything in the US Court system. Just look at all the collective Samsung vs Apple lawsuits. And I'm not even talking about one vs the other. They've BOTH sued each other and in some cases WON when they shouldn't have (Although Apple does seem to get away with this a lot more often).

I know, that's why I mentioned it in my argument. Apple vs Samsung isn't a great example, though, because those fights were mostly about patents and deisgn rights.

AMD can't be anti-competitive? Are you joking? Apart from blatantly lying about processor specs from the core count to the instructions per clock, AMD also completely fudged benchmarks back in 06-7-8 too. It's not about the money. It's about the practices. Lastly, you seem to forget AMD and Nvidia have been caught price fixing as recently as last year while also fudging the GPU capabilities of Tegra and Mullins. AMD is as corrupt and anti-competitive as any of them given the opportunity.

No, I'm not joking. Some of the shady deals Intel did are simply not possible for AMD because they lack the money.

And no, counting video and CPU cores together is not anti-competitive, it's just stupid - completely legal, but stupid.

Can you please provide sources on the IPC missmatch, the rigged benchmarks and whatever you meant to say about the GPU?

[Faa]

Now that is a blatant lie. It looked at the CPUID string and adjusted optimization settings to what was appropriate and available on a given architecture, and you could not find this AMD instruction set information online 10 years ago or even 5. The FTC had no right to force Intel to change its proprietary compiler. If AMD wanted the fastest code possible on Cinebench it would have provided its own compiler and allowed users to download Intel and AMD-tailored versions of Cinebench. Even today Intel still destroys AMD in Cinebench scores going back to 2009 chips.

It's not a lie, http://www.swallowtail.org/naughty-intel.shtml

When they swapped the CPUID AuthenticAMD with GenuineIntel the opteron did much better in one particular test but on the other side in a different test the opteron was destroying the Intel CPU with or without that patch. Highest I could find was the memory controller test which gained a 50% improvement; http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/

 

 

Not the first or last of anything, It was always the case that Intel nerfed the compiler and the anti competitive behaviour with pc vendors is a separate incidence. Proof below.

It sounds like Intel always performed better with the Intel compiler but it's not. Crippling/nerfing is a different story than willing to support and Intel however isn't even willing to support future products with older version of compilers. Also if we compare Intel vs AMD CPU's with AMD's own compiler we notice a bigger difference than we would with Intels compiler;

So why are Intel CPU's performing worse than AMD CPU's with AMD's compiler? Crippling? No. We clearly see AMD's caring more about their own CPU's with their own compiler than Intel CPU's which Intel has all the rights to do as well. Rigging benchmarks, well Teksyndicate making benchmarks like a 8350 outperforming a 3570K by up to 400%, a i7 doing 50% worse than a i5 when streaming or a cheap APU outperforming a 4770k by 50%, is all okay after they claim Intel was manipulating benchmarks and every other source except them are biased. Why would Teksyndicate fabricate benchmark results like this? Maybe something would have gone wrong with the Intel system? Ah he leaves JJ's rig out in the benchmark where he showed the APU being better than the 4770k. Thats the 2nd Intel platform they already used so assuming that one was defective as well makes no sense anymore. If you'd show their results which are pretty much different than any other source to a guy who completely has no understanding of CPU's at all would even admit they're BS. Logical reason to me is; money. That looks to be paid by AMD. Would be a rumor, but this Intel "crippling" story started as a rumor as well. 

Also thanks for sharing the links, was looking for those tests for quite a long time.

[mr moose]

Now that is a blatant lie. It looked at the CPUID string and adjusted optimization settings to what was appropriate and available on a given architecture, and you could not find this AMD instruction set information online 10 years ago or even 5. The FTC had no right to force Intel to change its proprietary compiler. If AMD wanted the fastest code possible on Cinebench it would have provided its own compiler and allowed users to download Intel and AMD-tailored versions of Cinebench. Even today Intel still destroys AMD in Cinebench scores going back to 2009 chips.

 

Oh Please, it was independently validated by three different sources (all of which are cited in the articles I linked).  It's not a lie. 

 

Unless you can find some proof to validate your position one can only assume you are in denial. 

[mr moose]

 

It's not a lie, http://www.swallowtail.org/naughty-intel.shtml

When they swapped the CPUID AuthenticAMD with GenuineIntel the opteron did much better in one particular test but on the other side in a different test the opteron was destroying the Intel CPU with or without that patch. Highest I could find was the memory controller test which gained a 50% improvement; http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/

 

 

It sounds like Intel always performed better with the Intel compiler but it's not. Crippling/nerfing is a different story than willing to support and Intel however isn't even willing to support future products with older version of compilers. Also if we compare Intel vs AMD CPU's with AMD's own compiler we notice a bigger difference than we would with Intels compiler;

So why are Intel CPU's performing worse than AMD CPU's with AMD's compiler? Crippling? No. We clearly see AMD's caring more about their own CPU's with their own compiler than Intel CPU's which Intel has all the rights to do as well. Rigging benchmarks, well Teksyndicate making benchmarks like a 8350 outperforming a 3570K by up to 400%, a i7 doing 50% worse than a i5 when streaming or a cheap APU outperforming a 4770k by 50%, is all okay after they claim Intel was manipulating benchmarks and every other source except them are biased. Why would Teksyndicate fabricate benchmark results like this? Maybe something would have gone wrong with the Intel system? Ah he leaves JJ's rig out in the benchmark where he showed the APU being better than the 4770k. Thats the 2nd Intel platform they already used so assuming that one was defective as well makes no sense anymore. If you'd show their results which are pretty much different than any other source to a guy who completely has no understanding of CPU's at all would even admit they're BS. Logical reason to me is; money. That looks to be paid by AMD. Would be a rumor, but this Intel "crippling" story started as a rumor as well. 

Also thanks for sharing the links, was looking for those tests for quite a long time.

 

 

I would expect any chip to perform better if the compiler was optimised for it, however the issue is not that Intels compiler favored their chips but that it misrepresented everyone else's.  It is widely accepted that there was no need for a compiler to execute instructions based on CPUid and therefore the chief complaint against Intel was that they knew the effect the compiler had on benchmarks and did nothing to address it:

 

"Intel failed to disclose material information about the effects of its redesigned compiler on the performance of non-Intel CPUs. Intel expressly or by implication falsely misrepresented that industry benchmarks reflected the performance of its CPUs relative to its competitors? products.?

 

 

As far as I know AMD haven't released a compiler that unnecessarily hinders another product without disclosing that.  ( I argue here that Intels poorer performance stems from lack of support as opposed to intentional crippling)

 

 

Don't get me wrong though,  I don't hate Intel or AMD, but the reality is right now I would not buy an AMD CPU because for me they suck.  However the facts are facts and we must decide what they mean to each of us as customers.

[patrickjp93]

I tried to understand the first sentence but I really can't, sorry. Can you please rephrase it?I know, that's why I mentioned it in my argument. Apple vs Samsung isn't a great example, though, because those fights were mostly about patents and deisgn rights.No, I'm not joking. Some of the shady deals Intel did are simply not possible for AMD because they lack the money.And no, counting video and CPU cores together is not anti-competitive, it's just stupid - completely legal, but stupid.Can you please provide sources on the IPC missmatch, the rigged benchmarks and whatever you meant to say about the GPU?

The most glaring crime of price fixing: http://www.xbitlabs.com/news/graphics/display/20080930220708_ATI_Nvidia_to_Pay_1_925_Million_to_Settle_Price_Fixing_Legal_Dispute.html

As per rigged benchmarks, do we really need to bring up the future mark scandals involving AMD buying off benchers when its architecture couldn't keep up with the GTX 500 series?

[patrickjp93]

 

It's not a lie, http://www.swallowtail.org/naughty-intel.shtml

When they swapped the CPUID AuthenticAMD with GenuineIntel the opteron did much better in one particular test but on the other side in a different test the opteron was destroying the Intel CPU with or without that patch. Highest I could find was the memory controller test which gained a 50% improvement; http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/

 

 

It sounds like Intel always performed better with the Intel compiler but it's not. Crippling/nerfing is a different story than willing to support and Intel however isn't even willing to support future products with older version of compilers. Also if we compare Intel vs AMD CPU's with AMD's own compiler we notice a bigger difference than we would with Intels compiler;

That also fails to mention the times those tests crashed because the compiler tried to use instructions AMD didn't have available (AVX 256-bit for one). Intel didn't nerd AMD at all. List I said, if AMD wanted to bitch, they could have provided the Cinebench makers their own compiler in order to release two versions. But no, they chose to get butthurt over it.

[patrickjp93]

I would expect any chip to perform better if the compiler was optimised for it, however the issue is not that Intels compiler favored their chips but that it misrepresented everyone else's.  It is widely accepted that there was no need for a compiler to execute instructions based on CPUid and therefore the chief complaint against Intel was that they knew the effect the compiler had on benchmarks and did nothing to address it:

 

 

As far as I know AMD haven't released a compiler that unnecessarily hinders another product without disclosing that.  ( I argue here that Intels poorer performance stems from lack of support as opposed to intentional crippling)

 

 

Don't get me wrong though,  I don't hate Intel or AMD, but the reality is right now I would not buy an AMD CPU because for me they suck.  However the facts are facts and we must decide what they mean to each of us as customers.

No need to check the CPUID?! ARE YOU CRAZY?! If it didn't it wouldn't be able to guarantee xyz instructions exist, effectively either crashing the program or causing an erroneous result. Back when this story broke Intel was the only one sporting 256-bit wide support. Try running that on legacy CPUs or on anything pre AMD FX. It'll crash or give back bad results. There is every reason to check CPUID string. Both Clang and GCC do it

[mr moose]

No need to check the CPUID?! ARE YOU CRAZY?! If it didn't it wouldn't be able to guarantee xyz instructions exist, effectively either crashing the program or causing an erroneous result. Back when this story broke Intel was the only one sporting 256-bit wide support. Try running that on legacy CPUs or on anything pre AMD FX. It'll crash or give back bad results. There is every reason to check CPUID string. Both Clang and GCC do it

The CPU dispatcher in the compiler checks the processor for supported instruction sets, it is then supposed to choose the best instruction for that processor,  there is no need to check the vendor ID. Yet, Intel's compiler did and then ran the slowest instruction it could for any chip not returning the genuine intel vendor id. SO -  No I am not crazy, now please if you are going to continue denying reality then provide some evidence. Don't just say it's wrong without support.

 

 

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.

 

 

 

There is no need to check vendorid, all the information the compiler needs for any processor that is not intel is contained within the supported instruction check.   Fair enough if they want to run specially optimised code for their own cpus, but it is not necessary to choose a specific instruction set based on the vendor id as the compiler already knows what instructions are supported.

[yoloswag9000]

The most glaring crime of price fixing: http://www.xbitlabs.com/news/graphics/display/20080930220708_ATI_Nvidia_to_Pay_1_925_Million_to_Settle_Price_Fixing_Legal_Dispute.html

As per rigged benchmarks, do we really need to bring up the future mark scandals involving AMD buying off benchers when its architecture couldn't keep up with the GTX 500 series?

So, ATI, not AMD.

Also, yes, please.

[patrickjp93]

Oh Please, it was independently validated by three different sources (all of which are cited in the articles I linked).  It's not a lie. 

 

Unless you can find some proof to validate your position one can only assume you are in denial. 

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!

[patrickjp93]

So, ATI, not AMD.

Also, yes, please.

2008 and 2009 ATI was already bought out.

[patrickjp93]

The CPU dispatcher in the compiler checks the processor for supported instruction sets, it is then supposed to choose the best instruction for that processor,  there is no need to check the vendor ID. Yet, Intel's compiler did and then ran the slowest instruction it could for any chip not returning the genuine intel vendor id. SO -  No I am not crazy, now please if you are going to continue denying reality then provide some evidence. Don't just say it's wrong without support.

 

 

 

There is no need to check vendorid, all the information the compiler needs for any processor that is not intel is contained within the supported instruction check.   Fair enough if they want to run specially optimised code for their own cpus, but it is not necessary to choose a specific instruction set based on the vendor id as the compiler already knows what instructions are supported.

Why bother with an instruction dispatcher when you can have a pre-made list and just use a switch statement or database to hunt for compatible chips? No one uses the dispatcher anymore. It's too slow going into the BIOS and SRAM onboard.

 

I have provided support! YOU MUST KNOW THE CHIP AND THE INSTRUCTIONS IT SUPPORTS AHEAD OF TIME TO MAKE THE DAMN COMPILER IN THE FIRST PLACE!!! It's 10,000% unreasonable to ask Intel to make a compiler for its competitor's chips when it doesn't know which chips have what (and no the dispatcher is not totally accurate), and Intel wouldn't the know the microcode labels for AMD's stuff anyway, and if it did know, that would involve reverse-engineering AMD's stuff. It's complete BS to expect that. Intel is innocent of any legal culpability due to the laziness of its competitors. And no, it didn't write the slowest possible code. It took the safe route. What could be guaranteed in that day and age? Since then AMD has actually most of the stuff required to make a strong compiler for its architecture, and for x86 on AM64, the intel compiler still beats out all competition handily.

[mr moose]

Why bother with an instruction dispatcher when you can have a pre-made list and just use a switch statement or database to hunt for compatible chips? No one uses the dispatcher anymore. It's too slow going into the BIOS and SRAM onboard.

this was 5+ years ago, what they do now is irrelevant.    Back then they used the CPU dispatcher to check for compatible instructions.   Intentionally choosing the slowest instruction based on vendor ID was wrong and what made it illegal was the fact it was not disclosed when it was known to illegitimately make their CPU perform comparatively better in benchmarks.

[patrickjp93]

this was 5+ years ago, what they do now is irrelevant.    Back then they used the CPU dispatcher to check for compatible instructions.   Intentionally choosing the slowest instruction based on vendor ID was wrong and what made it illegal was the fact it was not disclosed when it was known to illegitimately make their CPU perform comparatively better in benchmarks.

Nope. I even have the old ICC. It goes after the CPUID. That is how it's been done for years. Anyone who says otherwise is full of shit or an academic. There are too many variants and too many things which can go wrong when querying the chip for instructions. Not to mention those which get disabled after the fact but are still in the chip's bank of possible instruction (TSX-NI for Haswell for instance).

 

Intel didn't choose the slowest. It chose what it knew would be supported by most mainstream AMD processors at the time. Intel was guilty of nothing. It actually was disclosed too that its compilers could not and did not fully support competitors' architectures and instruction sets. Cinebench also isn't Intel's proprietary benchmark either. As I've said AMD could have written their own and contributed the binary to the Cinebench project.

[mr moose]

Nope. I even have the old ICC. It goes after the CPUID. That is how it's been done for years. Anyone who says otherwise is full of shit or an academic. There are too many variants and too many things which can go wrong when querying the chip for instructions. Not to mention those which get disabled after the fact but are still in the chip's bank of possible instruction (TSX-NI for Haswell for instance).

 

Intel didn't choose the slowest. It chose what it knew would be supported by most mainstream AMD processors at the time. Intel was guilty of nothing. It actually was disclosed too that its compilers could not and did not fully support competitors' architectures and instruction sets. Cinebench also isn't Intel's proprietary benchmark either. As I've said AMD could have written their own and contributed the binary to the Cinebench project.

 

Again, post, cite or reference something that supports what you are saying, as it is at odds with what everyone else is saying.

[patrickjp93]

Again, post, cite or reference something that supports what you are saying, as it is at odds with what everyone else is saying.

I have the software, I can disassemble it, and I can decompile it. It's not something you're incapable of doing. Also, the only people claiming it are people outside of Intel who can't publish its IP without being sued into their graves. Go ahead and get the student version of parallel studio 2015, which comes bundled with Intel's compilers. Run ObjDump or a similar disassembling program on top of either an instance of Cinebench or ICPC compiling a hello world program. If I publish a screenshot of dumped code then I'm violating copyright law. It's still something anyone can independently verify, and the method is simple and straightforward.

You're also asking me to cite proof of intent when no one in the world can prove Intel's intent one way or another. My explanation is a rational alternative to conspiracy theories wrung out by AMD fans in an effort to slander the leading chip designer and manufacturer in the world.

[mr moose]

I have the software, I can disassemble it, and I can decompile it. It's not something you're incapable of doing. Also, the only people claiming it are people outside of Intel who can't publish its IP without being sued into their graves. Go ahead and get the student version of parallel studio 2015, which comes bundled with Intel's compilers. Run ObjDump or a similar disassembling program on top of either an instance of Cinebench or ICPC compiling a hello world program. If I publish a screenshot of dumped code then I'm violating copyright law. It's still something anyone can independently verify, and the method is simple and straightforward.

You're also asking me to cite proof of intent when no one in the world can prove Intel's intent one way or another. My explanation is a rational alternative to conspiracy theories wrung out by AMD fans in an effort to slander the leading chip designer and manufacturer in the world.

 

So in other words you don't have anything.  I have linked to several articles which include quotes from legal action taken by the FTC and Links to people who have tested, proven and published a screenshot of the code in question. While your defense rests on you asking me to get a copy of the amended compiler which no longer has the offending code in it and disassemble it to prove what exactly? that the new compiler doesn't do it anymore?  

 

Please your arguments are getting so thin they don't make sense.    I don't want you to cite proof to intent, I want you to cite proof or at least link to supporting articles/documents for all the claims you make.

[patrickjp93]

So in other words you don't have anything. I have linked to several articles which include quotes from legal action taken by the FTC and Links to people who have tested, proven and published a screenshot of the code in question. While your defense rests on you asking me to get a copy of the amended compiler which no longer has the offending code in it and disassemble it to prove what exactly? that the new compiler doesn't do it anymore?

Please your arguments are getting so thin they don't make sense. I don't want you to cite proof to intent, I want you to cite proof or at least link to supporting articles/documents for all the claims you make.

Oh FFS. The FTC was a legitimate then as it is now: not at all. And no, I have the old, old compilers too. Even the current ones still look for the CPUID string. It's faster and less memory intensive than querying the chip for supported instructions. The difference now is Intel has tried to add more optimization for AMD-based chips, but AMD's own compiler will still do better in that regard due to greater familiarity with its own product.

The same offending CPUID check code is in ICPC 2015 as was in it in 2002. If you'd like to check the GCC and clang compilers, they are open source programs you're free to download the code to. I'm on my phone and headed to class, but it's there plain as day, the same leading CPUID check, no instruction set dispatcher.

https://www.gnu.org/software/gcc/releases.html

http://llvm.org/releases/download.html

[mr moose]

Oh FFS. The FTC was a legitimate then as it is now: not at all. And no, I have the old, old compilers too. Even the current ones still look for the CPUID string. It's faster and less memory intensive than querying the chip for supported instructions. The difference now is Intel has tried to add more optimization for AMD-based chips, but AMD's own compiler will still do better in that regard due to greater familiarity with its own product.

The same offending CPUID check code is in ICPC 2015 as was in it in 2002. If you'd like to check the GCC and clang compilers, they are open source programs you're free to download the code to. I'm on my phone and headed to class, but it's there plain as day, the same leading CPUID check, no instruction set dispatcher.

https://www.gnu.org/software/gcc/releases.html

http://llvm.org/releases/download.html

 

 

 

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. 

[yoloswag9000]

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.

If someone stubbornly believes that OpenGL is a programming language and that Intel has a proprietary OpenGL driver for linux against all evidence, I'd call this someone delusional. That might help with your question.

[mr moose]

If someone stubbornly believes that OpenGL is a programming language and that Intel has a proprietary OpenGL driver for linux against all evidence, I'd call this someone delusional. That might help with your question.

it certainly looks that way.