Does Intel’s compiler cripple AMD performance?

One of the claims in AMD’s sensational antitrust complaint against Intel has been getting some play around the web lately. Specifically, folks are focusing on what AMD says about Intel compilers and how they react to the presence of AMD processors. Here’s the meat of the claim, taken directly from the AMD complaint:

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

So AMD says Intel is sabotaging its CPUs with iffy compiler behavior.

We do use some benchmarks compiled with both the Intel and Microsoft compilers, such as LAME MT and Sphinx, just to see how different compilers affect performance. However, we couldn’t verify or dispute AMD’s claims based on that limited experience.

A gent named Mark Mackey has spent some time with Intel’s Fortran compiler for Linux, and his experiences would seem to back up AMD’s claims. (Thanks to Per Olofsson for the link.) After a bit of testing and looking into Intel’s CPU identification routine, he comes to this realization:

The code produced by the Intel compiler checks to see if it’s running on an Intel chip. If not, it deliberately won’t run SSE or SSE2 code, even if the chip capability flags (avaialble [sic] through the ‘cpuid’ instruction) say that it can. In other words, the code has been nobbled to run slower on non-Intel chips.

He then checks with Intel for a fix, looks at several version upgrades, and the problem basically persists. His solution? Patch the compiler to sidestep the CPU check, and run a few quick benchmarks. He finds that “patching out the ‘GenuineIntel’ check makes no difference to the P4, but increases the performance of the Opteron by up to 10%.” Yow.

His conclusions are sharply worded:

To Intel: there is a standard mechanism out there (invented by you!) for questioning a CPU as to its capabilities. You should be using that, not checking for the presence of your trademark. I don’t expect Intel to support AMD-specific extensions, and I also don’t expect Intel to have to test its compiler on AMD CPUs. However, if a CPU states that it can do SSE3 or whatever then I expect the code produced by the Intel compiler to use SSE3 instructions rather than to check first if the chip was made by Intel.

Perhaps Mr. Mackey is secretly an AMD partisan, but he seems to have done his homework. One wonders whether the Intel compilers’ SSE limitations on AMD processors extend beyond the Fortran compiler for Linux. This post on Slashdot would seem to suggest problems in the C++ compiler, as well.

Comments closed
    • Shintai
    • 14 years ago

    Maybe people should try and think alittle before declaring intel the big bad boy.

    Imagine you make a compiler that use SSE1-2-3/MMX/64bit and so on with any CPU that got them.

    Now you have to validate everything with every CPU. So basicly Intel would need to validate it´s compiler against any AMD, any VIA, any Transmeta CPU etc. And if it should bloody fail on another CPU using any extensions…damn I could smell lawsuit. Thats why the Intel compiler uses the failsafemode on non Intel CPUs.

    Imagine yourself, selling a car from vendor A, your customer changes the engine to Vendor B. But you as vendor A still have full responsiblity about anything on the car. Is that how business should be?

    Intel uses ALOT of money on quality testing, the same reason alot of people buy Intel. You buy assurance and quality. Not some perfect AMD cpu with some crappy nforce/via chipset on a too cheap taiwan motherboard that will fail before you even get to the point of upgrading.

      • SVB
      • 14 years ago

      Nice try Intel boy, but I don’t think you have thought it through. Everyone else sells software that runs on Intel, AMD, VIA and Transmeta processors. Microsoft comes to mind, along with every game manufacturer, Oracle… . The list is hundreds on companies long and none of them have a problem with lawsuits. But that’s not the point. The compiler worked perfectly on AMD processors until Intel dumbed it down. Intel took something that worked perfectly on AMD et al and took out the optimizations. All that does is make AMD look slow. Intel still sells the compiler to AMD users.

      Also remember that this compiler made AMD look better until Intel brought it and took out the optimizations for AMD.

      Second of all, the optimization is not using SSE, SSE2 or SSE3. It is taking out code redundancies for loops etc.

      Consider a similar situation. Mr. A and Mr I are racers. Mr. I reads the rules and realizes that he can make a modification to his fuel that gives him 50 more horsepower. What can Mr. A do? Nothing because Mr. I stayed in the rules.

      But suppose that Mr. I buys the fuel supplier and he ships fuel to Mr. A that contains sludge and water. Now Mr. I will get a rap on the knuckles and probably disqualified. If he does it repeatedly, he will probably get banned for life.

      You should also remember that Intel had a Fortran compiler prior to acquiring Compaq’s. So why did Intel abandon their old one and acquire Compaq’s. You need to answer those questions and not posit some unrealistic hypothetical.

      But lets go further. Both AMD and Intel validate their processors to run on the x86 instruction set. If they don’t perform the validation correctly, the processor doesn’t execute the code correctly. Just like the problem Intel had with the Pentium III where thaey ate thousands of processors that couldn’t do arithmetic properly.

      It’s also interesting that you shold mention 64 bits. That’s AMD’s 64 bits. Microsoft said that the only x86 64 bit instruction they would support would be AMD’s If Intel wanted a different instruction set, they would have to write their own operating system. So Intel must verify that EMT64 is fully compatible with AMD64 and not the other way around or so says Microsoft.

        • Shintai
        • 14 years ago

        Nice try calling me intel boy since I

          • SVB
          • 14 years ago

          You should read the url that you quoted from. The Intel Visual Fortran compiler was created by “the same great engineering team” as the Compaq Visual Fortran compiler. It’s the same team because Intel acquired the team and the compiler. HP still continues to sell the old version.

          The transfer of assets between HP and Intel was the subject of many articles at theinquirer. A reference is here: §[<http://www.chipzilla.com/?article=1544<]§ . Try emailing Mike Magee and I'm sure he could point you to the one about Visual Fortran. But you might look at this url: §[<http://cache-www.intel.com/cd/00/00/22/24/222439_222439.pdf<]§ . I suppose if Intel says they got the compiler from Compaq you'll believe it. As you will remember, HP originally started the EPIC instruction set which Intel used on Itanium. There was a deal between the two in June of 2001 that moved the "HP Visual Fortran" team to Intel, paid HP for the use of EPIC and moved the Alpha team to Intel where it was killed. As for validation, before AMD or Intel release a processor, they validate the microcode by running simulations agaist various pieces of software. The PC manufacturers validate the processors against the instruction set and the software manufacturers validate their software against the processors. Because of the cross licensing between AMD and Intel, both execute exactly the same instruction set with the same results. If it were not so, we would see another repeat of the P III math error problem where there was a small error in the last bit that would affect the results in repeated calculations. The AMD64 specification is published by AMD. You might look here: §[<http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594.pdf<]§ Intel has similar documents for MMX, SSE, SSE2 and SSE3. There is no need to reverse engineer and reverse engineering wouldn't do any good anyway since AMD uses a different microcode than any of the ones Intel uses. So the question is why did Intel want to acquire the Compaq Visual Fortran compiler, why did Intel change the SSE etc checks from a verification of the status registers in the Compaq version to checking for "Genuinue Intel." Why couldn't Intel have left the optimization to the user to decide instead of burying it. If there was an imcompatibility between the AMD and Intel instruction sets, don't you think there would be a big brouhaha about it. If someone could find and embarass Intel over the PIII problem, don't you think that someone else could find an incompatibility with the AMD instruction set other than this one: §[<http://www.gordonfamily.com/AMD/default.htm.<]§ Just as the PIII problem caused great embarassment for Intel, this one cause somewhat smaller embarassment for AMD. I think any reasonable person should realize that AMD processors must produce exactly the same results as Intel processors for a given piece of software. Otherwise someone would have found it and exploited it to the embarassment of AMD. I'm sure there are many people looking. PS. I don't think there are nearly 250 people total working on the Intel compiler much les than 250 additional. In graduate school, I wrote pass 1 of a compiler as a semester project for a compiler course. This group: §[<http://www.bloodshed.net/<]§ seems to be about 3 persons and many of the open source development efforts are about 10 to 12 persons. But you can also do the math. If 250 people are required just to verify and validate code for AMD, then 250 would be require for P4 and 250 would be required for celeron etc. At least 250 would be required to write the compiler. Soon you would have a staff of 2500 and at $250,000 per year for full loading, the cost of manufacturing the compiler would be $625 million. Double that for distribution costs etc and it soon becaomes apparent that Intel's Visual Fortran is a multibillion dollar a year operation. I don't think Intel sells anywhere near the 2-4 million copies a year that would support such an operation.

            • Shintai
            • 14 years ago

            You still lack to tell the business side of Intel needing to support and validate against AMD CPUs. And with the 64bit Windows you still need to explain why it didn´t work on EMT64 CPUs.

            If you think that Intel or AMD is basicly just handing over documents to each other and say. here this is how you implement SSE or AMD64. Then you are very wrong. Licensing a techonlogy is not the same as a copyrighted one. What the crosslicensing allows is to use the same technology, not the same implementation. Thats also why we see EMT64 not 100% compatible with AMD64 and the same with MMX, SSE1, SSE2 and SSE3. It´s all reversed engineered results.

            Also if you know alot about compilers and how to make one. You should know all the eratas thats basicly required today to have systems running stable. If you made a 100% bug free CPU today, it couldn´t run todays SW. You absicly need to implement the bugs for it to work. Aswell as make solutions for new bugs. And some of the new will be new permanent bugs. That 3 or 50 opensource people write compilers doesn´t apply for anything. Just take and compare how many people code on Windows compared to Linux or BSD.

            “If 250 people are required just to verify and validate code for AMD, then 250 would be require for P4 and 250 would be required for celeron etc. At least 250 would be required to write the compiler. Soon you would have a staff of 2500 and at $250,000 per year for full loading, the cost of manufacturing the compiler would be $625 million. Double that for distribution costs etc and it soon becaomes apparent that Intel’s Visual Fortran is a multibillion dollar a year operation. I don’t think Intel sells anywhere near the 2-4 million copies a year that would support such an operation.”

            I just said 250people, not 250 people per CPU. And I bet any revisions of AMD64, AMD64 X2, Semprons, Turions and so on ain´t much less that Intels CPU line. Add VIA C3 revisions etc. But basicly it´s a COST for intel. Not for AMD and it doesn´t benefit intel, nor does it make software not run. So it´s kinda simple that its a good decision to not do it. If someone released a game, using SSE2/SSE3 and it suddenly crashed on VIA C3 CPU. Who would you blame?

            “If there was an imcompatibility between the AMD and Intel instruction sets, don’t you think there would be a big brouhaha about it. If someone could find and embarass Intel over the PIII problem, don’t you think that someone else could find an incompatibility with the AMD instruction set other than this one: §[<http://www.gordonfamily.com/AMD/default.htm.<]§ Just as the PIII problem caused great embarassment for Intel, this one cause somewhat smaller embarassment for AMD. I think any reasonable person should realize that AMD processors must produce exactly the same results as Intel processors for a given piece of software. Otherwise someone would have found it and exploited it to the embarassment of AMD. I'm sure there are many people looking." See this is here the big world obviously overruns you. Just because AMD64 and EMT64 is not the same, it´s kinda easy to have a compiler that can make one binary supporting both. Kinda like the universal binaries for the MAC. Tho this is alot simpler. But I guess you wrinting a part of a compiler already knows this.

            • SVB
            • 14 years ago

            Read the posts and think.

            As I said earlier, Intel is under no obligation to make AMD look good but they are not allowed under antitrust law to screw them up. Intel cannot buy a compiler that AMD depends and screw it up just to make AMD look bad. Transmeta could, VIA could but Intel can’t because they have 83% of the market. There are a lot of thing that are good for Intel and bad for AMD but that doesn’t mean that antitrust law will allow them.

            But then on business sense, what is the business sense of Intel buying a compiler when they already have one. (Read the URL’s)

            As I said, Intel and AMD DO NOT use the same implementation because they have different microcode. (Read the post). They do have a court mandated cross licensing agreement so they can and do use the same instruction set.

            As for writing software and errata in implementation, read how it is done. I explained it to you and you should read it. The errata are faulty implementations and are taken care of in the BIOS. Your BIOS load contains updates to the microcode to take care of misimplementation of macro-instructions. That is why when you have a problem you may need to update the microcode to take care of the problems.

            Your comment about a 100% bug free cpu not running today’s sw is pure nonsense. Think about it. Every cpu ever made, Intel or AMD, has errata. They all have different errata because they all have different errors.

            Since they all run slightly different code then either the S/W doesn’t work and you need to update your BIOS or the S/W doesn’t use that feature. Either way, it’s not a problem fixed in the S/W but in the hardware. This of course doesn’t mean the S/W is bug free. Just that S/W bugs show up across all implementations.

            If you had read the AMD doc that I gave you a URL for, you would have seen how AMD and Intel describe the instructions. If AMD and Intel implement their microcode correctly, the instruction will produce exactly the same result on both machines.

            As far as business sense goes, I have managed S/W and H/W developments with large teams. A computer will take about 30 man years to develope starting at the chip level through shipping the box. S/W development is based on a lines per man-day metric. An average programmer will produce 10 to 15 lines per day for commercial code. For high rel code, the metric is about 4 lines per day. Before you say that you can do better than that, remember that the 10 lines per day includes design, code walk throughs, documentation, debug, integration and regression testing. Oh yes, and actually writing the code. A typical commercial compiler would be around 0.5 million lines of code. That would be about 200 man-years. So I would guess the Microsoft was probably about 50 for the Power Fortran implementation and the team size is probably down to 20 to 30 at Intel.

            But whether of not this is a COST for Intel, it was a COST they did not need to shoulder since Compaq was doing it for Intel, AMD, VIA and Transmeta and making money at it.

            Please answer this one question: Why did Intel feel the need to buy the compiler from Compaq. They were being supported by Compaq just fine. But so was AMD, … . What did Intel gain by gaining possession of the compiler? The answer is what has changed. And the answer is that the optimizations for AMD were crippled. The answer is so big and obvious that you cannot miss it even if you want to try to obscure it with sophmoric rhetoric. Intel got the compiler for the sole purpose of crippling the AMD optimizations. Optimizations which the AMD processors would run without error. Read the original article. The AMD crippling was disabled by Mark Mackey and guess what, it works just fine.

            Read my comments about errata and microcode and consider what I said in my previous post. If there were an imcompatibility, AMD would catch hell and would create an errata to be added to all the BIOS to correct the problem.

            Comment: The using of the BIOS to update the microcode seems to have been a response to Intel’s earlier problems with errata. My memory is dim on exactly the problem but as I remember, Intel had a problem with an implementation on the 286 or 386 and had to replace a thousands at the cost of almost $100 million. Since then, Intel and AMD have used an updateable microstore that was previously used on mainframes. The IBM 360 series (boy that goes back) loaded the microstore on boot. While Intel and AMD do not have enough writeable microstore to change the entire instruction set, they have enough to correct any reasonable amount of errata.

            You seemed to have the impression that code is forever locked into the cpu once it leaves the factory, I hope you now realize that’s not true. Every time you flash a BIOS, you are probably changing the instruction set.

            Neither Intel, AMD or Microsoft get their products perfect inspite of all the simulations and validations but they do find the errors and correct them so that the final result is that they run exactly as described in the manuals.

            And as far as instruction sets and manuals go, both Intel and AMD have copies of each others instruction set manuals where necessary. AMD implements x86, MMX, etc EXACTLY as described in the Intel manual. Intel implements AMD64 EXACTLY as described in the AMD manual. If you compare the EMT64 instruction set manal and the AMD64 instruction set manual, you will see that in many places, they are word for word identical. For that you may thank Microsoft because MS told both AMD and Intel they would only implement one x86 instruction set. (read that sentence again because it is important). SSE extensions come from the Intel manual and AMD64 (or EMT64) extensions come from the AMD manual. And he who does not implement exactly as described in the manual had better have errata ready or have butter for his toasted backside in the marketplace.

            If you need to reply, then I think you need to answer several questions: Why do you think pII, PIII, P4, celeron, k6, k7 and k8 would not be compatible and how often have you heard of a program failing because of a s/w incompatibility. I can name a few before 2000 but none since updateable microstore.

            Why did Intel acquire Visual Fortran from Compaq? What was in it for them?

            Why do you think that all of the thousands (millions ?) of program, operating systems, games could run on both AMD and Intel processors is the processors were not compatible? What is you example of an incompatibility?

            Why did Intel choose to use th “Genuine Intel” string rather than the SSE flags?

            Why was that method also used on the original Intel compiler and BAPCO benchmarks rather than the SSE flags?

            I agree that Intel does not have an obligtion to make AMD look good but since by demonstration by Mark Mackey (and many, many others), removing the test allows AMD optimazition to work on all know programs, would you no consider that messing in AMD’s knickers?

            Can you name any programs ever which were not properly optimized by the Intel compiler? If so, I will reinstall my copy and tst it out.

            What would you think is the antitrust implications of Intel because of their virtual monopoy position?

            One final question. Why did Intel have to hide the disimplementation of the optimizations? Why could they have just said this compiler is not guarenteed to work for AMD processors on their package since there could be no complaints from AMDroids who had been warned??

            Please don’t reply with I don’t know or understand because I have explained everything very exactly and have cited the URLs to back up my opinions. You should do the same.

    • SVB
    • 14 years ago

    Tht’s exactly what Intel’s page says in the first paragraph when describing all of their compilers. But what I have explained is that the Intel Visual Fortran compiler (originally Compaq) was specifically dumbed down for AMD processors. There were no improvements added for Intel processors. That action specifically harmed previous purchasers of AMD processors and that action is the basis of the antitrust allegation.

    • pedro_roach
    • 14 years ago

    This is what Intel says about there compiler as of 3:00 PM est 7/15/05

    “*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*.”

    It says right there that they are optimized for the Intel architecture.
    §[<http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219762.htm<]§

      • SVB
      • 14 years ago

      Maybe I could put it a little simpler. Intel is under no obligation to make AMD processors look good. But Intel cannot acquire third party software and altering it for the purpose of making AMD look bad. That’s messing in AMD’s knickers and that’s antitrust.

    • SVB
    • 14 years ago

    There is a lot of history to the “Intel” compiler that the readers should know in order to evaluate AMD’s complaint.

    The “Intel” compiler started life as Microsoft “Power Fortran.” It was sold to Compaq sometime in the late 90’s and became the Compaq Visual Fortran compiler. It’s Microsoft origins is why is has the name “Visual Fortran.”

    The compiler was subject to much controversy in 2002 and 2003 when BAPCO, who shared office space with Intel, created a set of benchmarks using the then Intel Fortran compiler. One of the items noticed by Van Smith of Vanshardware was that changing the string “Genuine Intel” to “Authentic AMD”(both 13 characters) significantly improved the scores of the AMD processors in the BAPCO benchmarks to the delight of the AMDroids. Many of the Intellitubies cried foul and said that you wern’t allowed to change the software on a benchmark to make a given processor run faster.

    One of the side discussions was that both AMD and Intel processors ran faster on the then Compaq Visual Fortran compiler. But AMD’s performance improved much more and was superior. Shortly after the controversy, BAPCO disappeared from sight and Intel acquired the Compaq Visual Fortran compiler and renamed it the Intel Visual Fortran Compiler. The same deal also saw the Alpha killed. (The Alpha was clearly superior to the then x86 processors).

    I was troubled by the deal at the time an I have always wondered why DOJ never objected. Anyway, the now Intel Visual Fortran compiler seems to produce code which runs very poorly on AMD processors and has the same objectionable test (“Genuine Intel” vs “Authentic AMD”) that the original Intel compiler used.

    It would seem to me that this is a clear case of buying a propduct that made AMD processors look good and “dumbing” it down. So while many Intellitubies may observe that there is nothing wrong with Intel writing a compiler which makes their processors look better than AMD’s, I find there is a problem with Intel buying third party software used by AMDroids and making it worse. The AMD customers were harmed and that is the basis of the antitrust complaint.

      • Craig P.
      • 14 years ago

      Note that prior to acquiring the Compaq compiler and development team, Intel had its own compiler. I’m not sure how much of the current compiler comes from Intel vs. how much comes from Compaq.

      As for why the DoJ wouldn’t have objected, aside from the obvious partisan snipes, there’s still a pretty substantial body of competition, AFAIK, although not necessarily in terms of market share. Lahey has made a compiler for the .NET development environment, although a quick look at Polyhedron indicates that it’s a dog performance-wise, and Absoft is still in the market.

    • Vaughn
    • 14 years ago

    Wow there is alot or bias intel people in here. What intel is doing with the compliers is wrong, checking for the instruction set and not the cpu type is what the complier should be doing as many have stated. Why would they license these to AMD then to just cripple the processors whnen trying to use these instructions! it is wrong plain and simple! it is irrelvant if AMD makes there own compliers or not. This act is anti competitive.

    • Shining Arcanine
    • 14 years ago

    I suppose someone in Intel doesn’t believe the compiler should trust a processor when it says it can do something but isn’t a GeniueIntel processor. I suppose this could be true but it really is a poor programing decision.

      • ripfire
      • 14 years ago

      You may say “poor decision” but AMD is saying that it was intentional.

      • Kurlon
      • 14 years ago

      Well, back in the day, weren’t there cpu’s (Cyrix?) that would claim support for some functions but run them incorrectly? Then you had some cpus (Again, Cyrix, 486DX2 I belive) that ran non-extension instructions flat out wrong in some cases… so you HAD to test for the cpu brand in addition to capibilities to ensure proper operation.

      In the end though, the Intel Compiler isn’t something produced for the good of man out of the goodness of their hearts, it’s a product to go along side their cpus. If they don’t want it to produce code for other cpus, thats their decision, there is nothing legally wrong with it.

      Intel doesn’t validate AMD cpus and how they handle the output of the compiler, that’ll probalbly be why they say they fall back to older code paths on non-intel cpus. They can’t guarantee they’ll work.

        • ripfire
        • 14 years ago

        You see, that’s the reason why AMD is pissed off at Intel. All this time, AMD is claiming to software developers that their processors are 100% compatible with Intel processors. In fact they even purchased licenses from Intel to ensure that compatibility. Now with Intel’s compilers, they’re saying “I don’t care if you’re 100% compatible, I’m only doing it for Genuine Intel processors and the developers will not know anything about it.”

        That, my friend, is anti-competition.

          • Kurlon
          • 14 years ago

          Anyone that uses a compiler from a cpu manufactuer and is surprised that it doesn’t support other cpu brands as well, is a idealist fool.

          And for refrence, my problem child Cyrix, was advertised as 100% compatible too… doesn’t mean it is. : )

            • swaaye
            • 14 years ago

            Excellent point.

            This reminded me of Folding@Home’s problem with SSE and AthlonXP CPUs that required a workaround. The same code locked up AXP’s while working fine on everything else. So, you see, there is always the potential here for problems. And you can’t possibly expect Intel to validate their own compiler for their competitors.

            • ripfire
            • 14 years ago

            /[

            • ripfire
            • 14 years ago

            Yeah, that would be true for the paranoid. However, that is not the case on what Intel is advertising for their C++ compiler:

            §[<http://www.intel.com/cd/software/products/asmo-na/eng/compilers/220009.htm<]§ If you read their notes on the bottom, it says: y[

            • Kurlon
            • 14 years ago

            Touche, I concede the point. I was not aware of that advertising.

            I’ll just step out of the rotation here… put the ball back into play… Let me know when I can come off the bench again! 😛

    • Baker
    • 14 years ago

    Does anyone know any details regarding the AMD/ Intel SSE/SSE2/SSE3 licensing agreement?

    As a layman, the way I see it is that AMD licensed these instruction sets from Intel only to have Intel actively prevent their usage on its cpus with a actively mass-marketed product aimed at developers creating code for all x86 platforms.

    To use the Ford analogy, I see this as being equivalent to Ford:

    1) Having the monopoly on car sales
    2) Licensing an engine component to its competitors, which they pretty much have to license because all new forms of fuel will seek to use it for optimal performance
    3) Then selling a widely used form of fuel (sold as being optimised for Ford cars, but capable of running in any car), which, in additional to not using the new engine component, actively misfires when it detects it is running in a non-ford engine(as suggested by these stories regarding “per byte” memcpy).

    Am I right with this?

      • Forge
      • 14 years ago

      The agreement is a flat, no-fee, across-the-board tech cross-license. ANYTHING AMD develops is available to Intel, and vice versa, no restrictions.

      In theory, Intel could tape out the Athlon64, err Pentium 5, tomorrow. All the tech is cross-licensed, though not chip design. They still reverse-engineer each other’s hardware the old-fashioned way.

      Now that I mention it, I wonder if bus technology qualifies. If so, we could get LGA775 Athlon64s (sans memory controller) or socket 939 Pentium Ds (with on-die mem controller added). Wouldn’t that be an ugly sight?

        • ripfire
        • 14 years ago

        I think Intel would have to become a member of the HyperTrasnport consortium to work.

    • LicketySplit
    • 14 years ago

    Pork?? Naw…really?? #5 should know:)

    • Forge
    • 14 years ago

    FWIW, I can confirm that the Intel compilers (all of them) on the Linux side at least, check for Intelhood before considering using SSE/SSE2/SSE3. I’ve been watching for a while and Intel has said a few times that they’re happy with the way the Intel check works.

    For me, the legitimacy of their claim went out the window when a P4-optimized binary will fall back but still use SSE1 when a P3 is detected, but an Opteron gets no SSE1 nor SSE2. If they’re checking for capability, that’s fine, but checking for ‘GenuineIntel’ is not kosher. Just my 0.02$, though.

    • radioactive21
    • 14 years ago

    Here’s something that no one has thought about. Remeber that Intel’s partnership with Apple can result in OSX going on to the PC market. That means that Microsoft will get kicked between the legs.

    Intel and Microsoft have a very tough relationship that is why Intel has been trying to court Apple for years now. Microsoft doesnt like Intel’s move towards Apple, because that means that Intel is trying to go into Microsoft territory. Thnk about it Intel x86 running MAC OSX, who wouldnt oggle at those words.

    Remember that Microsoft has been a big AMD supporter with its 64bit and so forth. It doesnt come as a surprise that AMD is fileing a suit right after the Intel/Apple partnership was announced.

    Hasnt anyone notice how Microsoft has been a background noise these past few months, being quiet about Intel/Apple and softly settling law suitsl like with IBM.

    Watch Microsoft being a major player once the AMD/Intel suit goes big. Microsoft always has a part in these kinds of schemes. Microsoft wants to hurt Intel for stepping over to the Apple.

    • dalamar70
    • 14 years ago

    The best analogy I can come up with is if you use Microsoft FrontPage and think you’re generating a “clean” web site. But what if the site only opens properly in IE because they explicitly disable some basic features like CSS in other browsers, even though the features are actually supported?

    (Disclaimer: This is a fake scenario (AFAIK)).

    • data8504
    • 14 years ago

    Edit: the title of this article is misleading. It should be “Does Intel’s Compiler only Accelerate Intel CPU Performance?”

    Hold on, wait. What?! In no way is making my compiler only perform faster on my chip, anti-competitive. Now, if I made my compiler explicity work slower on other chips, that would be. There IS a difference, as trivial as it may seem.

    Herbal Essences shampoo works better when followed by Herbal Essences conditioner… “But I wan’t to use Suave!” So sue Clairol? No!

    Come on! I made my compiler for me. I give it to people who understand it is made for my chips, (pro-AMD developers DO NOT use the Intel compiler because it doesn’t even compile on non-GenuineIntel systems) and I understand that I may make some people mad.

    But in the end, I do want JUST my chips to succeed! That’s the point of all business ventures. I mean… would anyone create a business to be *just* second?

    If AMD wants a good compiler, make it on their own. For now, I will make mine for my chips.

    Besides… it’s not as if the compiler says “If AuthenticAMD then make slower.”

      • Forge
      • 14 years ago

      (pro-AMD developers DO NOT use the Intel compiler because it doesn’t even compile on non-GenuineIntel systems)

      Incorrect.

      Not only does ICC 9 compile just fine on my AMD64 Linux box, it also compiles working AMD64 code. It just runs like crap due to getting MMX/noSSE/noSSE2/noSSE3 and a lot of brain-damaged code in the non-extended stuffs.

      I’ve got to Google up this patch to ICC/IFC quick. Sounds pretty kick ass.

      • notfred
      • 14 years ago

      y[

    • Ardrid
    • 14 years ago

    Can’t say I’m surprised about all this. It wouldn’t be the first time Intel has used anti-competitive measures to show themselves in a more favorable light. I’m about to read the full complaint (very interesting stuff since I’m in law school right now), but I hope AMD pulls this one out. Hell, if they could get evidence on Dell alone it would be enough to win the case.

    • Shintai
    • 14 years ago

    What is the problem here?

    That AMD don´t make their own compiler?

    Or that Intel maybe don´t wanna boost it´s compiler on AMD chips, or using the failsafe method so the compiler wont crash something.

    It´s pretty simple, if you are unsure..go the safe path. And you have no extra enchancements. I can´t really see a problem here. Unless you actually want an unfair business model were intel have to help and boost performance on AMD CPUs with it´s own compiler.

    Also the crash part is a pipedream. Performance difference yes..crash..no. I have both AMD and Intel systems, and I have coded for both. And it´s not like the standard compilers does any good for any CPU. So basicly when Intels compiler is used, we get same performance on AMD chips (or better in most cases), but always better performance on Intel chips. If thats a problem for AMD, I still wait to the enjoyment of buying a compiler from them…when they make one.

      • cass
      • 14 years ago

      There is no problem at all… I mean AMD and intel have cross licensed each others technology.

      The under handed and fraudulent part is that no where does Intel state specifically that their compiler produces slower code for all x86 processors except Intel. That essentially makes the cross licensing agreement worthless to AMD.

      From a legal standpoint, Intel is also a market driver…and they have a different set of rules because of anti trust and monopoly laws.

      It would be like ford disabling two cylinders of all jaguar V8 cars using their eec system and still trying to sell them as V8 while allowing all genuine ford products to run on all 8 cylinders.

      This AMD/Intel is going to be a lot of noise and he said/she said for a while, but eventually there will be some clear points coming to light on both sides. Articles and discussions like this will simply be amusement for us onlookers.

        • Anomymous Gerbil
        • 14 years ago

        “That essentially makes the cross licensing agreement worthless to AMD.”

        Wrong. There are other compilers available that make use of the SSEx instructions, so it’s just wrong to say that the cross-licensing is of no value to AMD.

    • totoro
    • 14 years ago

    It’s not about “optimizing for only your own products” !
    If intel makes a compiler that uses SSE,SSE2, or SSE3 optimizations, they should work on ALL chips that have those instructions.
    NOT just “Genu ineI ntel”.
    At the very least, let people KNOW that the compiler opt’s will only run on intel gear. Blatant BS to suggest otherwise.

    (IIRC, the “cross-licensing agreement” was really about not having the right to sue if one company reverse-engineers the other company’s chips/instruction set. Correct me if I’m wrong, gerbils.)

    EDIT: oh, and WRT #4, the odor of “the other white meat” is definitely drifting ovah heah.

    • swaaye
    • 14 years ago

    I’ve been thinking this was the case for years. Why hasn’t this been realized sooner? It makes total sense for Intel, the competitor, to make it’s compilers do goofy things for their competition.

    Sure it’s evil, but is Intel really in the wrong? I mean they are out to win not put millions into compiler development that helps AMD too. Does AMD deserve a free-ride compiler? Maybe Intel should be required to put something like “optimized for Intel CPUs” on the info sheet.

    It’s an interesting argument. I don’t think AMD can afford to develop their own compiler. It would take years and years too…. Obviously I’d think Intel’s compiler will always be faster than MS’s, but I’ve also read that Inte’s compilers are a bitch to use.

      • WaltC
      • 14 years ago

      q[

        • swaaye
        • 14 years ago

        I’m saying that it’s Intel’s product. They don’t have to go out of their way to make sure everyone runs optimally do they?

        I have been running AMD chips since 2001. It’s not like I love how this is working out lol.

        Obviously it would work out wonderfully if AMD, whose chips are designed to work with similar optimizations to Intel’s chips, could use Intel’s compiler with millions and millions put into it by Intel…..

          • WaltC
          • 14 years ago

          I don’t think you understand. In the instances highlighted here, Intel went out of its way to make sure AMD wouldn’t run SSE *at all*…;) Has nothing to do with “optimally,” unfortunately. The idea was to create the impression that Intel cpus perform better than they actually do when compared with AMD’s.

          I have no problem with Intel making a faster processor when and if that should happen–I have a big problem with Intel trying to make me believe it’s faster through the vehicle of benchmarks compiled with x86 code that attempts to run 386 code on an Athlon instead of SSE–while the Intel cpu by comparison is indeed running the mandated SSE instructions.

          That’s cheating everyone who looks to the benchmarks to provide an even-handed comparison between the performance of the competing architectures.

          • spworley
          • 14 years ago

          No, Intel doesn’t need to go out of its way to make sure the competition runs optimally. That’s not what’s happened. Instead, Intel has gone out of their way to make sure their competition runs more poorly.

          What Intel’s compiler produces:
          if (CPU==Intel && CPU has SSE) UseEfficientFastCode();
          else UseSlowEmulationCode();

          The correct code which works 100% of the time on all CPUs:
          if (CPU has SSE) UseEfficientFastCode();
          else UseSlowEmulationCode();

          This is not the only Intel-specific compiler issue that people have found, but it’s probably the easiest to understand and definately has an impact.

      • Soldier
      • 14 years ago

      People like you are why the Fed’s passed the Monopoly anti-trust laws…

      Not only is it wrong to attempt to make your products look faster than they are by hamstringing the competition, but its illegal due to breach of contract because AMD licensed the rights to SSE/2/3….

        • swaaye
        • 14 years ago

        Oh give me a break.

        I’m just saying that it is INTEL’s damned compiler! It’s their product. Nobody has to use it. Many developers don’t because it doesn’t work so hot for some things.

        Lol. Evil INTEL! BOO!

        AMD can rely on MS’s compiler can’t they? Intel just needs to specifically say that this is designed for their chips and they are in the clear IMO.

        Do I buy Motorcraft oil for my Chevy? Or Yamalube for my SkiDoo? No I don’t mix cuz you don’t know if it’s gonna work out, even with standards on the box. Ideally you go 3rd party because they are the people with a reputation to uphold for everyone.

        • Anomymous Gerbil
        • 14 years ago

        “but its illegal due to breach of contract because AMD licensed the rights to SSE/2/3…. ”

        Huh? That contract is between Intel and AMD regarding AMD’s processors. It says nothing about whether Intel has to write a sensible compiler.

        Clearly, this is a stupid move on Intel’s part, but it seems unlikely that it’s illegal. Sure there should be some description of the compiler’s behaviour as part of the product description, but is not having that description illegal, especially if Intel doesn’t claim that the compiler produces 100% optimal code on AMD processors?

          • ripfire
          • 14 years ago

          The problem is that Intel did not disclose on their compiler that the SSEx will only work for genuine Intel processors. Therefore developers who are using Intel compilers are unaware of such limitations, thinking that their programs should run the same on all x86 based processors. Once they see these programs run on Intel and AMD, they would say “Oh, I see Intel has a *better* processor than AMD, and would recommend users of their program to use Intel.”

            • Anomymous Gerbil
            • 14 years ago

            OK, but that doesn’t sound like a *legal* problem, is all I’m saying.

            • Klopsik206
            • 14 years ago

            Baring in mind Intel’s dominant position, and the their own claims the compiler *does* support AMD – I guess it *is* legal problem.

            Fingers crossed AMD 😉

      • Craig P.
      • 14 years ago

      Intel did buy out the Compaq compiler and associated development group, so I’m not sure if, at this point, it’s still i[

    • Mr Bill
    • 14 years ago

    (1) Time for a rematch with some recompiled benchmarks?

    (2) Is it a DMCA violation to patch a compiler so it skips the “GenuineIntel” trademark check?

    • Prion
    • 14 years ago

    Wasn’t this the root cause of why the fsck we K8 proc users can’t get QMD core work units from Folding@Home? The SSE2 capability is on the chip but they can’t compile the core to use the instructions on A64/Opty chips. Disgusting.

      • Ragnar Dan
      • 14 years ago

      So maybe Stanford should use different compilers?

      There’s a difference between Intel’s actions being unwise, which we may all consider them to be, and wrong, which so far I’ve seen nothing to indicate, except in that they may be harming themselves long-term by trying to keep ahead of their competitor(s) by such tactics instead of getting better hardware to market sooner.

    • Thresher
    • 14 years ago

    Didn’t Microsoft get burned for similar behavior by not revealing API’s in Windows to outside vendors? If I recall, that was the basis for their initial injunction.

    • spworley
    • 14 years ago

    I found this issue myself about a year ago via a post on comp.arch. Since then I’ve post-processed my Intel C compiler executables to remove the “GenuineIntel” trademark check. I admit I would have never figured it out on my own, it was that posting that gave me the knowlege and tool to do it.

      • spworley
      • 14 years ago
        • indeego
        • 14 years ago

        There is also an “edit” button over here:_____________________________▲

      • Namarrgon
      • 14 years ago

      Yeah, we’ve compiled Fusion with the Intel compiler for ages, it really makes a difference. With the advent of the dual Athlon & Opteron though, we noticed this sneaky behaviour ourselves, as of the last few years at least, and have also been patching our executables to do the check properly…

    • droopy1592
    • 14 years ago

    Posts on Ace’s Hardware talked about this stuff years ago. The AMD CPUs would show a flag for SSE2 but not utilize it anyway if the program was compiled with Intel compilers.

    Intel pushes that on software developers for that extra 10%.

      • wof
      • 14 years ago

      Don’t forget that Intel has an army of programmers helping people to optimize for their CPU’s and yes they are suggesting that people they help use their compiler.

      Edit: wasn’t meant to be a reply to #12

    • bhtooefr
    • 14 years ago

    I’m going to agree with this…

    The /. story was kinda screwy about stuff, FWIW.

    However, I agree that it should check for the necessary x86 extension in the CPUID – it seems like a no-brainer, unless, of course, you’re trying to run the slow codepath on a non-Intel chip.

    I’ve also heard (on the /. article, though) that it’s actually checking for a Pentium 4 (or, probably, a Pentium M will also do). If it doesn’t see one, it’ll run a non-MMX, non-SSE, non-SSE2 codepath. That’s right, it discriminates against the P3 as well. Not even fscking MMX!

    And, apparently the assembly code that it generates in the slow codepath is braindead code that isn’t even recommended for the *[<8086<]*, let alone a P3 or AMD chip...

      • dragmor
      • 14 years ago

      Before the P4 the Intel compiler was optimised for the P3, when Intel released the P4 it released a new compiler with SSE2 support, this produced noticeably slower executables on the P3.

      Basically Intel crippled the P3’s to make the P4 look better.

    • Intel Rules
    • 14 years ago

    The fact of the matter is SSE, SSE2 and SSE3 are Intel’s intelllectual property. AMD processors really don’t have *genuine* SSE, SSE2 and SSE3 instructions…they are reversed engineered versions of them. For example, AMD’s SSE3 is missing instructions related to Hyperthreading. Thus it’s really NOT SSE3, but a bootlegged version.

    I too would see no reason to support such reverse engineering of my intellectual property if I were Intel. In fact, if I were Intel, I would make it so the ICC would simply refuse to compile for AMD processors.

    The fact is this lawsuit is nothing more than a PR stunt by AMD. It has no legal basis whatsoever.

      • Damage
      • 14 years ago

      Pork pork pork pork!

        • 5150
        • 14 years ago

        I definetly smell a pork product of some type.

        edit: At least he’s more forthcoming this time with his user name.

          • PerfectCr
          • 14 years ago

          I actually feel bad for him. Maybe he needs to see the “Find a Geek Girl” thead in the forums 😀

            • bhtooefr
            • 14 years ago

            No, he doesn’t.

            You see, when the geek girls go out with the porcine poster, they’ll be scared away from geek guys. Therefore, when geek guys like me (who started that thread) try to go out with the geek girls, they’ll remember porky, and run the other direction…

            • indeego
            • 14 years ago

            Women aren’t stupid — 5 seconds with The Bacon and they will smell his kind a mile away. We’ll be fineg{<.<}g

        • leor
        • 14 years ago

        damn, it’s messed up when the site owner dogs you like that . . .
        he’s usully all wise and impartial 😛

      • Kurlon
      • 14 years ago

      Intel is being a bit overzealous by only honoring cpuid capibility bits when the core comes back as an ‘Intel’ cpu, but it’s easy to bypass in the compiler, and it doesn’t specifically target AMD, but ANY non-Intel cpu. I think it’s a bit foolish to tell a company that when they develop a support product for something they produce, that they have to make it work equally well with a competitors product.

      I don’t see anyone clamoring for Oracle to adapt their management software to handle MySQL or PostgreSQL… : )

      • bhtooefr
      • 14 years ago

      Hmm… cross-licensing ring a bell?

      Remember when Intel tried to stop AMD from second-sourcing the 386, and AMD won, and they had to share each other’s tech?

      I smell some bacon frying 😉

      • 5150
      • 14 years ago

      So what’s the case with Intel and EM64T? Isn’t that AMD’s intellectual property rights?

      • Logan[TeamX]
      • 14 years ago

      And Intel’s EM64T – Enhanced Memory 64-bit Theft… I mean Technology is the AMD X86-64 instruction set with a few changed instructions pertaining to lower efficiency and higher heat generation. What’s your point?

      At least AMD knows how to implement their competitor’s instruction set. Intel can’t even get the the TDP right, and hasn’t for almost three years now.

      Perhaps they ought to rename NetBurst to NovaBlast while they’re at it, to make their products more thermally-descriptive.

      • Thresher
      • 14 years ago

      Gah. This remark is assinine (or maybe porcine).

      AMD has a license for SSE1, 2, and 3. What intel is actually doing is nullifying that license by making their compiler ignore it CPUs that aren’t manufactured by them.

      This isn’t just anticompetitive, it’s also breach of contract.

        • Anomymous Gerbil
        • 14 years ago

        “This isn’t just anticompetitive, it’s also breach of contract. ”

        Only if the contract stipulates that Intel’s compilers will support the SSEx extensions on AMD processors, which clearly would seem not to be the case. People get confused between contract law and what “seems right”.

      • Lord.Blue
      • 14 years ago

      Uhmmm….wrong. Check your facts. AMD is able to use anyhting Intel comes out with, and in reverse Intel can use anything AMD comes out with. Part of an old Lawsuit settlement way back in the day…

      • Forge
      • 14 years ago

      Incorrect. AMD’s K8s fully support 100% of SSE and SSE2. They ignore MONITOR and MWAIT in SSE3 because they have no HT to apply those to. They are 100% functional, though, since the two mentioned instructions are not just SSE3, but SSE3+HT dependant.

    • nagashi
    • 14 years ago

    AMD chips don’t technically support ALL of SSE3. I believe there are 2 instructions that apply specifically to hyperthreading.

    What would happen if those instructions were passed to an amd chip? would it silently error? or crash the program?

    See, I can see intel turning on sse3 for amd chips, and when programs start crashing because they’re calling those 2 instructions on athlons, Intel can point their finger at AMD and say it’s their fault for not implementing ALL of sse3.

      • yokem55
      • 14 years ago

      Intel has this problem as well though. The PentiumD has hyperthreading disabled, and it has “full” support for sse3. Regular Prescotts also will be effected by this if for whatever reason, hyperthreading is disabled in the bios.

      • spworley
      • 14 years ago

      It’s not an issue. Athlons do support all SSE3 instructions, including the HT ones. They properly treat those HT opcodes as no-ops. No crash, no issues, no problems. Intel’s own SSE3 processors do the exact same thing if they do not support HT or if HT is disabled.

      • wof
      • 14 years ago

      A program running those instructions on a non hypethreaded machine deserves to crash …

        • Soldier
        • 14 years ago

        So do you…

    • Logan[TeamX]
    • 14 years ago

    It’s quite evident, especially in video rendering programs and encoding programs where Intel boxes run away with the performance crown. As a counter-point, I’m sure we’ve all seen what happens when AMD64 boxen run Windows Media Encoder – it’s a straight-out slaughter.

    When AMD implements SSE2 support, Intel introduces SSE3. It’s not enough for them to have to compete on an “even playing field”, they have to tilt the table in their favour 24/7. I can accept the new instruction set. I CAN’T accept the deliberate crippling of supported instruction sets for performance (and not compatibility) reasons.

    It’s like walking onto a used car lot, and the salesman knowingly sells Intel cars. He takes you out in a V8 car… it hauls ass. He then takes you out in an AMD turbo 4-cyl. It hauls just as fast as the Intel, but uses less gas to do it. Disgusted, the salesman pulls one of the sparkplug wires before you test-drive the car, and then reconnects the wire immediately thereafter.

    That’s misrepresentation of your competitor’s product by a deliberate action on your part. Last I checked, that’s cause for a lawsuit. But please don’t try the case in Canada. They’ll get a slap on the wrist and their own TV spot upon release from prison.

    • pwdrhnd23
    • 14 years ago

    I can’t believe I am gonna do this…..First Post!

    Wasn’t there something with Window Media Encoder a while back when the AXP first got SSE? I think it had something to do with Sysmark. So I think the idea is not really that new.

      • Soldier
      • 14 years ago

      Media Encoder was looking for the same Genuine Intel flag and not the SSE flag as proper programming would dictate…basicaly due to Intels compilers for C++ I believe, but dont quote me 😉

        • totoro
        • 14 years ago

        LInkage: §[<http://www.geek.com/news/geeknews/2002jan/bch20020110009707.htm<]§ I think this one's on the Microsfties, though (not compilers). Who knows, really; it's been such a long time.

        • pwdrhnd23
        • 14 years ago

        That is what I thought, thank you for verifing.

        So with that being said, there really is some possiblity that other programs or benchmarks that have been compiled forcing AMD down a standard path while Intel gets all the short cuts.

        Does that mean all the Spinx tests that TR has done are not showing the real potential of the AMD chips?

Pin It on Pinterest

Share This