Slashdot Mirror
AMD Alleges Intel Compilers Create Slower AMD Code
edxwelch writes "In AMD's recient anti-trust
lawsuit
AMD have examined the Intel compiler and found that it deliberatly runs code slower when it detects that the processor is an AMD.
"To achieve this, Intel designed the compiler to compile code
along several alternate code paths. ... By design, the
code paths were not created equally. If the program detects a "Genuine Intel" microprocessor,
it executes a fully optimized code path and operates with the maximum efficiency. However,
if the program detects an "Authentic AMD" microprocessor, it executes a different code path
that will degrade the program's performance or cause it to crash.""
Anyone following the GCC maining lists knows this. It has come up many times there in the past few years.
In other news...
They'll probably be convicted and then buy the regulators like MS so they only get a slap on the wrist.
On that note, was there *anything* negative that came of the Microsoft monopoly ruling?
More
Not being a compiler or chip guru, how does one work out that a compiler favors a specific chip? I can understand that it might be easy to detect code that looks for a specific chip, but then how do they determine that the resultant code is being optimized based on that detection?
Usually by decompiling the code produced. AMD probably made a test program, compiled it, found a chip test routine in the resulting binary, then decompiled the 2 code paths it could follow.
For example, the "intel" code path could, for example, make full use of the math coprocessor to perform a division, while the "non-intel" code path could use only the 16 bit registers and make multi-precision divisions with only the basic x86 instruction set. I'm sure the actual de-optimization (if it occured) involves higher, cleverer functions than just divisions, but that's the general idea.
Because a compiler just spits out machine instructions, it's a trivial task to compare the instructions from one code path to another.
For example, you write some code that would typically use SSE2 regisers when compiled, then you compile the code for each processor, and check to see if it used SSE2 registers on each, or if it ouput slower "emulation" style instructions on the AMD.
I thought someone said there was going to be free beer!
Also, the lawsuit claims that Intel's compiler wont use x86 ISA extensions such as SSE2 even when they're available on AMD processors. There is a reason we have these kinds of ISA extensions, and it is becaue performance is much much better when you use them.
The submission is old news. Anyone who read the earlier AMD antitrust documentation knew about this claim. It's among the things Intel has done to drive AMD to dirt.
However, what's news, is that EU antitrust investigators raided Intel and some OEMs today...
http://theinquirer.net/?article=24554
They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...
It is true but the article is misleading.
It does not target AMD negatively, but rather targets Intel positively. There is a huge difference.
When the compiler runs into a "genuine Intel" CPU it knows exactly how to compile the code paths to get the maximum performance. When it compiles everything else it needs to take the "safe" route and compile it as best it can (sometimes not very good at all)
Not a deliberate attack on AMD but rather a boost one would expect from a company that is providing a compiler and CPU's.
Wouldn't you expect an AMD compiler to take advantage of EVERY possible tweak it could to make code compiled for AMD processors run faster? Why call Intel the devil for doing the same thing?
http://en.wikipedia.org/wiki/Hanlon's_razor
The compiler optimizes for the Intel by using CPU-specific extensions to the x86 architecture such as SSE, MMX, 64-bit capabilties, etc. The Intel compiler simply fails to detect the capabilities in AMD chips (by not identifying AMD chips as supporting those features, and sticking with generic 386 or 586 code), and thus the result is code that runs slower.
My blog
It doesn't matter what CPU is used for compiling. It happens when the code is executed. The code looks at what CPU it is running on, if it's an Intel, it runs the good code, if it's an AMD, it runs the bad code. At least that's what AMD is claiming.
That's not what AMD is saying. RTFA. AMD is saying that their chip will run the same binary code produced for the Intel chip. They are saying that Intel deliberately creates substandard code when it detects and AMD chip.
Jack Valenti and Orrin Hatch will be first up against the wall when the revolution comes.
The combination of libstdc++, cygwin and GCC are a very slow combination due to the less-than-lightning-fast implementation of posix threads on Cygwin and the false economy of memory pools in libstdc++. It is not uncommon to see STL heavy c++ code run 4 times slower under Windows/g++ than in Linux/g++ for these reasons. If you switch to STLport (based on the original SGI STL) for Cygwin/g++ you will see a marked improvement in speed because it does not attempt to reuse nodes in maps and other STL containers.
Normally for a particular block of C code the complier only generates one block of machine code. There are places you could generate better optimized machine code but doing so depends on the features exisiting in the CPU that do not exisit in all CPUs. To get around this you and generate both the optimized machine code as well as the generic machine code and place a condition that determines during runtime what code gets executed.
The filing actually has a ton more complaints than just what the poster mentioned. Here is the relevant section:
c. Intel's Leveraging of Its Other Product Lines to Unfairly Disadvantage
AMD in the Marketplace
122. Intel has also designed and marketed microprocessor-related products with the
goal of compromising performance for those who opt for AMD solutions, even if it requires
sacrificing its own product quality and integrity.
123. An example is Intel's compilers. Generally, independent software vendors
("ISVs") write software programs in high-level languages, such as C, C++, or Fortran. Before
these programs can be understood by a computer system, they must be translated into object
code - a machine-readable language - by a software program called a compiler. Different
companies write compilers for different operating systems (Windows, Linux, etc.) and for
different programming languages (C, C++, Fortran, etc.). Intel offers compilers for use with a
variety of different operating systems and programming languages.
124. Intel's compilers are designed to perform specialized types of optimizations that
are particularly advantageous for ISVs developing software programs that rely heavily upon
floating point or vectorized mathematical calculations. Such programs include, for example,
mathematical modeling, multimedia, and video game applications.
125. Intel has designed its compiler purposely to degrade performance when a program
is run on an AMD platform. To achieve this, Intel designed the compiler to compile code
along several alternate code paths. Some paths are executed when the program runs on an Intel
platform and others are executed when the program is operated on a computer with an AMD
microprocessor. (The choice of code path is determined when the program is started, using a
feature known as "CPUID" which identifies the computer's microprocessor.) By design, the
code paths were not created equally. If the program detects a "Genuine Intel" microprocessor,
it executes a fully optimized code path and operates with the maximum efficiency. However,
if the program detects an "Authentic AMD" microprocessor, it executes a different code path
that will degrade the program's performance or cause it to crash.
126. ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors, or third-party
compilers, which do not contain Intel's particular optimizations. Sadly for AMD and its
customers, for legitimate reasons Intel's compilers appeal to certain groups of ISVs, especially
those developing software programs that rely heavily on floating point and vectorized math
calculations. Unbeknownst to them, performance of their programs is degraded when run on
an AMD microprocessor not because of design deficiencies on the part of AMD, but
deviousness on the part of Intel.
-- thalakan
Compiler optimization is a tricky business, and optimizing for one platform can actually slow performance on another.
The story is light on details and doesn't say if the compiler is generating code optmized for the P4 or if it's code supposedly optimized for the AMD or if it was one of those "blended" things. If it's optimized for P4, then I can easily see how intel's instruction ordering can be beneficial for them, and slow the AMD.
Things like pipeline length and differing branch predictors can cause wildly different results on different CPU's.
I really don't see how Intel is under any obligation to optimize their compiler for AMD.
If you need web hosting, you could do worse than here
If they intentionally bloated the machine code for AMD processors, then that is wrong.
If you RTFA you'll see that AMD is charging (and numerous sources are confirming) that Intel did extra work to specifically make things slower when programs compiled with their compiler were run on an AMD. On previous poster even posted his two line partial fix for the issue that drastically improved code speed and which he gave to Intel while trying to solve this issue with the compiler. Basically it just tricked the compiler into always using the copy function for Intel processors. This was obviously malicious.
Yes, and no.
No, if it was using proprietary 'processor specific improvements (TM)'.
However, it is *not*.
The real answer (not Intel's answer), is Yes, because Intel's compiler (which is widely regarded as producing some of the fastest binaries out there) produces code that will only take advantage of standard processor extensions (MMX, SSE, SSE2, SSE3) on 'Genuine Intel' Processors. Regardless of whether or not AMD processors support these extensions, the code excutes in slower, emulation mode if it does not detect 'Genuine Intel'.
When you 'fake' the compiler out by having all processors return 'Genuine Intel', the compiler generates code that will utilize standard extensions that it recognizes (everything but 3DNow, and 3DNow-2), on *any* processor that supports them.
This means your athlon will run SSE code, and your athlon 64 will run SSE,SSE2, and SSE3 code.
Not to mention MMX code, which Intel even disables for non-Pentium 4 Intel processors, even though Intel processors have supported MMX since the Pentium MMX!
This kind of manipulation is clear, and the only purpose is to portray the Pentium 4 as superior, and both older Intel processors and all AMD processors would appear siginificantly faster if the compiler simply utilized whatever extensions where avaliable (on the order of 10-40% for some programs) rather than relying upon the 'Genuine Intel' flag.
Intel *is* a monopoly, and although it is not illegal for a monopoly to exist, monopolies, under current U.S. law, are not permitted to use predatory tactics, especially when going from one market to another (compilers->processors).
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
I can see where you're coming from, but this isn't just a case of not caring how code performs on your competitors hardware. A byte-by-byte memcpy on x86 is basically insane, and can only be described as willfully crippling non-intel CPUs.
You should really read this, it's pretty amazing. After AMD offerred HP 1 million processors to compete with Intel Retaliation, Intel upped the stakes, and HP backed down.
I for one am VERY scared about the new Apple Intel adoption. I've always been an AMD fan, but prices of late, as well as difficulting getting "approved" systems for my video editing software has made me purchase Intel for my last 2 machines. (Though I type this on a barton 3000).
I don't think Intel has been driving the innovation bus, and if you thought Microsoft was the bad guys, I have a feeling you aint seen nothin yet.
> It is much much harder to write a compiler that generated good and fast code (now you need hundreds of experienced engineers working for years)
:
This assumption is wrong
see here and here
if it wasn't for licensing hiccups the plan9 c compiler would be OpenBSD's default by now
"I am sorry for the strong minded way in which I am approaching this,
but I am very dissapointed [sic] that after years of requesting that the
plan9 c compiler become free so that we can start extending it and
working with it... that we could be rebuffed in such a way because the
lawyers have not been properly reined in." Theo de Raadt
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
This won't be hard to prove. Pretty much anyone who wants fast 32Bit code uses the Intel Compilers, even on AMD. However it is a known fact that you need to force the compiler to use optimizations if an Intel Processor is not detected.
I work in a computer simulation lab. We have something like 50 AMD processors running code we compiled with the Intel Fortran Compiler and it's been working great for the past two years now. We have a mixture of Athlons and Opterons. Everything is workin' great. No problems. We used to use the Portland Group's fortran compiler until we found that the Intel Fortran Compiler generates faster executables. This was the case for both 32 and 64 bit executables. Started out with Portland Group, switched to Intel...and it works great for us!
Not for the last few years, in fact AMDs x64 line runs a lot cooler than any Intel processor I've seen.
http://www.acm.org/classics/sep95/
Read Ken Thompson's classic paper on just that. He makes the case that it would, in fact, be not terribly difficult to hide code that does exactly what intel is being accussed of in an open source compiler, without anyone ever knowing it was there.
Take a look at this page for an example. Also, try here.
Maybe you can do what this guy did, if you haven't already seen it.
No;
The Compiler produces MMX, SSE, SSE2, and SSE3 optimized code, but will revert to emulation and pure integer/floating point processing if it does not detect 'Genuine Intel' and 'Pentium 4'.
It's not a question of producing optimal code in terms of processor configuration; that's a gimme. Its a question of not even permitting competitor processors to utilize standard processor extensions, including *older* intel processors that support a partial subset of those features.
Athlon 64s, by the way, support all of these, and operate perfectly, if they are tricked into reporting 'Genuine Intel'.
AMD is not asking Intel to have the compiler produce code that takes advantage of the Athlon architecture; there could be different optimizations because of the Athlon's better memory architecture, or lesser penalty for misprediction, and shorter pipeline.
No, AMD is asking that Intel not produce a compiler that intentional disables standard processor extensions for non-Pentium 4 processors.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
I guess it depends on what you're calling "correct" HTML. If you're going by the W3C standard, very, very few sites are up to snuff. I worked as my school's web master for a couple of years, and because I had nothing to do, I decided to bring the code up to W3C XHTML standard.
Wow.
That process of rewriting the code to standards was not only a pain in the butt, but it also broke it on IE. This was one of my many aggravations while working at that job (that and traversing the byzantine bureaucracy (cool... alliteration)). Microsoft goes off on their own weird tangents with IE and throws the standard to the wind, while Firefox sticks with it, but at the same time is choking itself because very few sites out there write to standards.
The only way to tell the difference between a hamster and a gerbil is that the hamster has more white meat.
Dear AMD,
please show us what compilers you have developed that take full advantage of your oh-so-superior CPUs.
Well?
Nothing, huh?
Not even one fucking compiler.
Thought so.
If you're too lazy to read the postings here shows such evidence.
It's an example showing the poor assembly-language code when it detects an AMD chip. And notice in that posting that the complier is perfectly capabile of producing efficient AMD code as well. It's sad but funny that the workaround to produce fast code for the AMD chip is to add the string "__intel_cpu_indicator=-512".
We do. The company I work for makes a very comprehensive graphics application, designed to deal with images from film and higher (thing 4k images at float point).
There are a lot of companies who take performance very very seriously. We are just one of them.
The problem here has nothing to do with crashing, it has to do with the problem that companies that have chosen the Intel compiler for it's excellent performance suddenly find themselves producing software that is much slower on AMD systems than it needs to be.
The options are to switch to a different compiler and take the performance hit that comes from that (which can be quite significant) or put pressure on Intel to stop trying to 'innovate' using underhanded tactics.
Since we can hack around the problem for now by tricking the compiler into thinking our AMD is a Intel, I choose to try pressuring Intel before we try switching.
- sarcasm is just one more service we offer -
Care to comment on http://www.devx.com/amd/Article/28001 ??
A single jump instruction, and you have to flush the entire pipeline!
That's patently not true
Look, the issue is this:
The compiler doesn't need to be optimized for AMD's chips. But it does need to be optimized for extensions which Intel supports. The claim is that Intel's compiler DOES NOT support their own extensions when an AMD chip is detected.
This is important because the Intel Compiler is used to compile benchmarks, enterprise level code, demonstrations, etc. Business decisions to go with one chip or another are based on the performance of the software, which was compiled from the Intel Compiler, which claims to be able to support the INTEL extensions.
By crippling the resulting code when the compiler detects an AMD CPU, Intel is essentially LYING about the performance of their processor and about the performance of the AMD processor through resulting benchmark software(s) and applications compiled with the Intel compiler.
Yes, AMD can make their own compiler, but people have to choose to use it. People who are already using the Intel compiler invested time and money into creating a development environment based on it. Switching isn't easy. If the compiler makes the AMD cpu look bad, businesses will choose to go with Intel thinking those processors gave them better bang for their buck, when the opposite might be true.
It's like having two cars that can do 125MPH, but one has been electronically locked to max out at around 85MPH, then putting them on a racetrack to determine which car is faster.
That isn't a valid comparison. And if INTEL's compiler IS purposefully generating substandard code that doesn't even support their own extensions in AMD's cpus, then benchmarks compiled with the Intel compiler are similarly invalid.
This could also mean contractual violations between AMD and INTEL since AMD licenses the enhanced extensions from INTEL.
It ISN'T about INTEL's compiler not optimizing itself for AMD specific instruction sets. It is about INTEL's compiler not optimizing itself for INTEL specific extensions on AMD CPUs, which AMD has license from INTEL and implemented in their processors.
Another way of looking at it is that AMD has licensed enhancements believing that INTEL's compiler will similarly take advantage of those enhancements. Perhaps that was in the agreement, perhaps not.
If it was the case, then AMD should be furious. They basically licensed and implemented extensions, from INTEL, into their processors that INTEL is choosing to not support. Not because it isn't compatible, the extensions were implemented to their specifications, but to be anti-competitive and deceptive in the intent of their licensing of the extensions.
A simple: if ( intel cpu) { optimized code + extensions } else-if ( amd cpu ) { standard code w/o extensions} is overly simplistic for an engineering organization like Intel and would be difficult to explain away since they are licensing their extensions.
The compiler should be checking for the existence of extensions and choosing to compile in functionality or not. Most games and graphics packages use dynamic libraries and alternate blocks of code for different extensions detected. If small, mid-sized, and large game companies can do thi
Winged Power Photography
If the GNU people can make a compiler for every fricking chip on the planet on their own dime, surely AMD can write a good C / C++ compiler for their chips.
Hey, maybe instead AMD could pay people to work on GCC. Oh, wait, they do that already. Why do you think GCC was ported so quickly to AMD64? GCC development is not, AFAIK, funded much (if at all) by the FSF anymore. It's all Apple, AMD, IBM, the various Linux vendors, etc.
I'll take an open source compiler that is installed everywhere over a commercial one that is only on a handful of machines.
command line switches to turn on support for various things.
"My opinions are my own, and I've got *lots* of them!"
Well, they do require quite a lot of cooling, don't they?
Have you ever looked at a P4 mother board? The real estate for the fan is easily double what it is on an Athlon motherboard.
The only way to tell the difference between a hamster and a gerbil is that the hamster has more white meat.
1) Intel's compiler does NOT support AMD's CPUs/ eng/vtune/220001.htm
http://www.intel.com/cd/software/products/asmo-na
2) Only a moron would buy Intel's compiler to develop for AMD processors (even if they didn't know about 1))
3) From TFPDF: "ISVs are forced to choose between Intel's compilers, which degrade the
performance of their software when operated with AMD microprocessors,"
How exactly are ISVs forced to choose "between" Intel's compilers? Those developing on AMD should NOT use Intel's compilers in the first place since Intel does not support that CPU.
(BTW, ISVs are not forced - they are enticed - to choose Intel's compilers. Can they prove Intel forces ISVs to buy their compilers?)
5) From TFPDF: "Unbeknownst to them, performance of their programs is degraded when run on
an AMD microprocessor not because of design deficiencies on the part of AMD, but
deviousness on the part of Intel."
Unbeknownst to them, the fucking product page does not even list AMD processors as supported. What do they expect? "Blistering" performance?
A single jump instruction, and you have to flush the entire pipeline!
:-)
That's patently not true
Fair enough. A single mis-predicted jump will flush the entire pipeline.
Thanks for the correction.
Javascript + Nintendo DSi = DSiCade
Why would AMD expect the Intel compiler to produce optimized code? because of theis from Intels websight.
"Accelerate Windows* Applications
Develop high-performance software for desktops, servers, handheld devices and mobile phones that is optimized for Intel® architecture using Intel® Compilers for Windows*."
Note is says Intel architecture, which AMD processors are compliant with, not Intel processors. Therefore, I would reasonably expect that claim to be substantiated in the resulting code.
For about a year, I've been patching my Intel Compiler compiled code because of this issue. I have to give credit to a poster on the comp.arch newsgroup for an explaination of ONE of the issues, and a workaround.
This is not the only anti-Athlon trick in the compiler, but it's an easy one to verify and understand.
From: iccOut (iccout2004@yahoo.com)
Subject: sleazy intel compiler trick (SOURCE ATTACHED)
View: Complete Thread (4 articles)
Original Format
Newsgroups: comp.arch
Date: 2004-02-09 14:38:40 PST
As part of my study of Operating Systems and embedded systems, one of
the things I've been looking at is compilers. I'm interested in
analyzing how different compilers optimize code for different
platforms.As part of this comparison, I was looking at the Intel
Compiler and how itoptimizes code.The Intel Compilers have a free
evaluation download from here:
http://www.intel.com/products/software/index.htm?i id=Corporate+Header_prod_softwr&#compilers
One of the things that the version 8.0 of the Intel compilerincluded
was an "Intel-specific" flag.According to the documentation,binaries
compiled with this flag would only run on Intel processors andwould
include Intel-specific optimizations to make them run faster. The
documentation was unfortunatelylacking in explaining what these
optimizations were, so I decided to do some investigating.
First I wanted to pick a primarily CPU-bound test to run, so I chose
SPEC CPU2000.The test system was a P4 3.2G Extreme Edition with1 gig
of ram running WIndows XP Pro. First I compiled and ran spec with the
"generic x86 flag" (-QxW),which compiles code to run on any x86
processor.After running the generic version, I recompiled and ran
spec with the "Intel-specific flag" (-QxN) to see what kind of
difference that would make.For most benchmarks, there was not very
much change, but for 181.mcf, there was a win of almost 22% !
Curious as to what sort of optimizations the compiler was doing to
allow the Intel-specific version to run 22% faster,I tried running
the same binary on my friend's computer.His computer, the second test
machine, was an AMD FX51, also with 1 gig of ram, running Windows XP
Pro. First I ran the "generic x86" binaries on theFX51, and then
tried to run the "Intel-only" binaries. The Intel-specific ones
printed out an error message saying that the processor was not
supported and exited.This wasn't very helpful, was it true that only
Intel processors could take advantage of this performance boost?
I started mucking around with a dissassembly of the Intel-specific
binary and found one particular call (proc_init_N) that appeared to be
performing this check. As far as I can tell, this call is supposed to
verify that the CPU supports SSE and SSE2 and it checks the CPUID to
ensure that its an Intel processor. I wrote a quick utility which I
call iccOut, to go through a binary that has been compiled with this
Intel-only flag and remove that check.
Once I ran the binary that was compiled with the Intel-specific flag
(-QxN) through iccOut, it was able to run on the FX51. Much to my
surprise, it ran fine and did not miscompare. On top of that, it got
the same 22% performance boost that I saw on the Pentium4 with an
actual Intel processor. This is very interesting to me, since it
appears that in fact no Intel-specific optimization has been done if
the AMD processor is also capable to taking advantage of these same
optimizations. If I'm missing something, I'd love for someone to point
it out for me. From the way it looks right now, it appears that Intel
is simply "cheating" to make their processors look better against
competitor's processors.
Links:
Intel Compiler:http://www.intel.com/products/software/in dex.htm?iid=Corporate+H
Metrowerks no longer produces an x86 compiler toolchain:
u lt.htm
http://www.metrowerks.com/MW/Develop/Desktop/defa
"Metrowerks recently sold its Intel x86 compiler and debugger technology to a third party. As a result, Metrowerks will no longer create and sell products that include this technology. Metrowerks will offer support for these products by hosting on-line discussions on newsgroups and on our web site.
This sale does not affect the right to use CodeWarrior or create x86 code by customers currently licensed to use CodeWarrior x86 compilers."
Cyric Zndovzny at your service.
Try it with http://slashdot.org/ - www.slashdot.org redirects to slashdot.org.
A good investigation can be found at http://www.swallowtail.org/naughty-intel.html
They just refuse to turn on many optimizations unless they see "GenuineIntel" returned from the CPUID instruction. Thus excluding _everyone_ else.
At least they're being fair about it. *eye roll*
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
That's just not feasible. Unlike Intel, AMD isn't huge and they don't have a massive software team. However, they aren't stupid and have funded and helped develop compilers. In particular gcc received a lot of help from AMD, especially in developing the AMD64 target.
The enemies of Democracy are
Nope. Metrowerks was spun off with, and belongs to, Freescale. Which you would know, had you done something so simple as go to their home page and read the words: "Metrowerks - A Freescale Semiconductor Company".
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
This is a case where a compiler can go "if it is a 'processor-type-a' use these instructions otherwise use something else". I don't see any fault here. Intel has created a compiler that uses their chip's optimal settings. An efficient instruction set of instructions for a P4 will not be the same for an Athlon anyway due to internals of both chips being different. Why would anyone believe otherwise?
Because "anyone" would know that certain code paths are going to be faster on both AMD and Intel processors than others. An SSE2 optimized code path is going to be faster on both chips than an x87 code path. Yes the chips are different but both do better with certain kinds of code.
Why would this be the case? Because AMD tried to make their SSE2 support as fast as possible so that it could run the same code as an intel compiler just as fast! AMD is not in a position to expect everyone to optimize their code for the underdog's processors. They have to make sure the code that exists runs fast.
Yes, they are going to be differences in the most optimal sequence of instructions depending on the microarchitecture of the chips. This does not mean that the optimal code path for Intel is automatically sub-optimal for AMD. Why would you assume that?
You don't see any fault because you aren't comprehending the situation. The CPUID instruction returns, among other things, a bit field detailing all of the instruction set extensions supported by the chip. AMD processors have supported SSE2 for years, and have this bit set. These instructions are quite fast on AMD processors, because they have to be. The Intel compiler produces code that uses SSE2, and other instructions if the compiler doesn't support it. However to determine which code path to use, the Intel-generated code uses the processor name returned by CPUID rather than the feature bits. It checks for "GeniuneIntel" or "AuthenticAMD", and uses either the fast code path or the slow one.
It has nothing to do with compatability, and everything to do with detecting and crippling a competitor's chip.
The enemies of Democracy are
AMD is currently working with the Free Software communinity (including working with both SUSE and Red Hat) to improve GCC support on its platforms. At present, there are no direct contributions from AMD to the Free Software Tools, but that will change in the future.
It would be one thing if the compiler always spit out binaries that ran only on Intel CPUs and errored out when attempting to run on anything else, but it's churning out a multi-path binary that sets up all sorts of unnecessary hurdles for execution on non-Intel CPUs and sends all CPUs not returning a "genuine Intel" ID string down that path. There are already standard methods of determining whether a given CPU is SSE2 instruction compatible, and it's not done by checking the CPU manufacturer. The fig leaf of "ensuring compatibility on unknown hardware" just doesn't cover their actions here.
If a job's not worth doing, it's not worth doing right.
He did it to show that even theoretical attacks, which have never been seen in the wild, can be effectively mitigated out of existence.
Never forget that the Open Source development community have been working towards providing more secure environments, whether you make use what is available is up to you.
maow.