Forgot your password?
typodupeerror
AMD Government Intel The Courts News

AMD Alleges Intel Compilers Create Slower AMD Code 912

Posted by CmdrTaco
from the getting-a-little-spicier dept.
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.""
This discussion has been archived. No new comments can be posted.

AMD Alleges Intel Compilers Create Slower AMD Code

Comments Filter:
  • by DeadSea (69598) * on Tuesday July 12, 2005 @11:41AM (#13042874) Homepage Journal

    That is an outragous claim! No company would stoop so low. Why, that would be like claiming that Microsoft configured its servers to give broken HTML to browsers other than Internet Explorer. That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. That would be like saying that Adobe publishes pdfs that b0rk XPDF.

    Anybody can see that this claim is ludicrous and that things like this just don't happen. (but I hope I'm not giving anybody any ideas.)

    Type your currency conversion into a free form text box

    • by cwebb1977 (650175) on Tuesday July 12, 2005 @11:44AM (#13042928) Homepage
      Hey, Microsoft doesn't even know the difference between correct and broken HTML!
    • by dsginter (104154) on Tuesday July 12, 2005 @11:44AM (#13042930)
      In other news... [yahoo.com]

      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?
    • Re:Simply ludicrous (Score:5, Interesting)

      by RootsLINUX (854452) <{moc.liamg} {ta} {xunilstoor}> on Tuesday July 12, 2005 @11:46AM (#13042951) Homepage
      Well, I don't think they would make such a claim without at least some sort of evidence. And we all know that Intel is a corporation that doesn't like to play nice with the other kids. During my senior year of undergrad my computer architecture professor consistently refered to Intel as "the evil empire", so who knows. I'd like to see AMD present some hard evidence though.
    • " That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. "

      Can you find an instance of Apple ever giving MP3's to play in the iPod?

    • That is an outragous claim! No company would stoop so low. Why, that would be like claiming that Microsoft configured its servers to give broken HTML to browsers other than Internet Explorer. That would be like saying that Apple gave away free MP3s that work in the Ipod but that crash other music players. That would be like saying that Adobe publishes pdfs that b0rk XPDF.

      (that should have been followed by the obligatory:)

      oh wait...
  • by haluness (219661) on Tuesday July 12, 2005 @11:41AM (#13042876)
    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?
    • by pcidevel (207951) on Tuesday July 12, 2005 @11:47AM (#13042974)
      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.
    • by the_weasel (323320) on Tuesday July 12, 2005 @11:48AM (#13042976) Homepage
      Which is exactly what we did when we discovered this. And sure enough, when the Intel compiler thought our AMD was a Genuine Intel certain functions increased dramatically.

      The company I work for submitted a few reports on this a few months ago, as I am sure did many others. I am very pleased to see them following up on it.

    • by truesaer (135079) on Tuesday July 12, 2005 @11:48AM (#13042986) Homepage
      Its easy to write a compiler that generates working code for a processor (My team of 3 people in a Compilers class wrote an x86 compiler, front to back, in about 8 weeks). 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). Essentially what you do is use really basic and crappy alogorithms for one code path, then use your best optimization algorithms for another path. Now, you just use the crappy path for one processor and the good path for the other, based on the value returned by the CPUID instruction. Viola!


      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.

      • by DrSkwid (118965)
        > 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 [bell-labs.com] and here [bell-labs.com]

        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... t
    • by thalakan (14668) <jspence@noSPam.lightconsulting.com> on Tuesday July 12, 2005 @12:02PM (#13043190) Homepage
      Because the Intel compiler actually generates multiple copies of routines, then figures out which one to call at run-time based on a processor detection routine they stick in the program. Example:
      [thalakan@shaitan ~]> icc -axKWNPB -c test5.c -o test5.o
      test5.c(3) : (col. 16) remark: main has been targeted for automatic cpu dispatch.
      [thalakan@shaitan ~]> nm test5.o
      00000000 r _2il0floatpacket.1
      00000008 r _2il0floatpacket.3
      00000020 r _2il0floatpacket.5
      00000028 r _2il0floatpacket.7
      U __intel_cpu_indicator
      U __intel_cpu_indicator_init
      U __intel_proc_init
      00000000 T main
      000000f2 t main.A <-- SSE version
      00000028 t main.H <-- x87 version
      U printf
      U rand
      U targets
      U time
      [thalakan@shaitan ~]>
      The remark about automatic CPU dispatch is the compiler notifying you it's going to generate multiple copies of the routine.
    • by jejones (115979) on Tuesday July 12, 2005 @12:25PM (#13043467) Journal
      Take a look at this page [swallowtail.org] for an example. Also, try here [devx.com].
  • by dame4jc (811440) on Tuesday July 12, 2005 @11:43AM (#13042911)
    if ($submission) {
    $gotaco = "submit";
    $spellcheck = "no";
    $dupecheck = "definitelynot";
    } else {
    // I got nothing. *shrugs*
    }
  • by 1967mustangman (883255) on Tuesday July 12, 2005 @11:43AM (#13042912)
    I am huge AMD fan myself, but this has me a little worried. If they can really prove their claims great for AMD, but if not I fear they risk looking like SCO and becoming the brunt of many jokes.
  • by th1ckasabr1ck (752151) on Tuesday July 12, 2005 @11:43AM (#13042914)
    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.

    If that statement is true, wouldn't there be programs all over that ran fine on Intel but crashed on AMD? Maybe there are and I haven't noticed? Maybe not many people use Intel compilers?

    • by digidave (259925) on Tuesday July 12, 2005 @11:53AM (#13043051)
      Not to mention the fact that AMD still benchmarks very favorably in games and other CPU-intensive applications, so the slowdown can't be huge.

      However, I doubt AMD would claim this if it weren't true. They still have a business to run, unlike SCO, and don't want to damage their reputation.

      I suspect that the "crash" part is more conjecture than fact, since the unoptimized code paths might be assumed to be lower quality in many ways. Or perhaps AMD found a single instance of a crash that occurs in one of the unoptimized code paths and even if Intel didn't mean for it to be there, they're still on the hook for that path in the first place.

      I have a feeling AMD has been working on this lawsuit for several years, so it will be interesting when they do finally submit the evidence to the court.
    • They won't crash. They will use slower methods of moving and processing data.
    • by Gopal.V (532678) on Tuesday July 12, 2005 @12:10PM (#13043287) Homepage Journal
      > wouldn't there be programs all over that ran fine on Intel but crashed on AMD?

      Most Linux development is done using GCC , Most of windows with MSVC++. Only true hard-core inner-loop optimising geeks usually use Intel C/C++ compilers. These are people like game devs, crypto developers and HPC programmers.

      So yeah, there's a lot of code that doesn't work with Amd64 when compiled with ICC. But how many people build stuff on Amd64 with an Intel compiler ?. (remember this is not valid for stuff compiled on a pentium 4 but running on amd64)
      • by the_weasel (323320) on Tuesday July 12, 2005 @12:33PM (#13043569) Homepage
        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.

  • by Eponymous Cowboy (706996) * on Tuesday July 12, 2005 @11:43AM (#13042922)
    I noticed this problem back in January of 2004, with Intel C++ 8.0, and went through heck over nine months with Intel's customer support to get it fixed until I eventually had to abandon their compiler.

    On any non-Intel processors, it specifically included an alternate code path for "memcpy" that actually used "rep movsb" to copy one byte at a time, instead of (for example) "rep movsd" to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I'd ever seen, and was around 4X slower than even a typical naive assembly memcpy:

    push ecx
    shr ecx, 2
    rep movsd
    pop ecx
    and ecx, 3
    rep movsb

    They responded with completely ridiculous answers, such as:

    "Our 8.0 memcpy was indeed optimized for a Pentium(r)4 Processor,when we reworked this routine we used the simplest, most robust, and straightforward implementation for older processors so that we didn't need the extra code to check for alignment, length, overlap, and other conditions."

    BS. I went and added the following line to the beginning of my source code:

    extern "C" int __intel_cpu_indicator;

    then I added:

    __intel_cpu_indicator = -512;

    to the "main" function.

    This forced Intel C++ to use the "Pentium 4" memcpy regardless of which processor in in the machine. It turns out that their special "Pentium 4" memcpy which I tested thoroughly in all kinds of situations, and it worked perfectly fine on an AMD Athlon and a Pentium III. I pointed this out to them.

    I received the following response:

    "The fast mempcy is over 2000 lines of hand coded assembly, with lots of special cases where different code paths are chosen based on relative alignment of the source and destination. ... If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?"

    I answered "No," saying that I needed support for AMD processors as well. I also gave them a copy of my own memcpy routine that was 50% faster than theirs--and just used MMX. They closed the support issue and did nothing to resolve it.

    I switched back to Visual C++.
    • Wow... that's a great example, and you should gather as much evidence of it as you can, especially Intel's responses, and send it to AMD's legal team.

      MOD PARENT UP
      • by hackstraw (262471) * on Tuesday July 12, 2005 @01:01PM (#13043954)
        Wow... that's a great example, and you should gather as much evidence of it as you can, especially Intel's responses, and send it to AMD's legal team.

        If I were Intel, I would respond with the product description of the Intel compiler, as found here http://www.intel.com/cd/software/products/asmo-na/ eng/compilers/clin/index.htm [intel.com] or here http://www.intelcompiler.com/ [intelcompiler.com].

        The product is clearly labeled as a high performance compiler for Intel CPUs. The grandparent used the wrong tool for the job which required a generic compiler.
        • by Dun Malg (230075) on Tuesday July 12, 2005 @05:22PM (#13047381) Homepage
          The product is clearly labeled as a high performance compiler for Intel CPUs. The grandparent used the wrong tool for the job which required a generic compiler.

          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.

    • by Penguin Programmer (241752) on Tuesday July 12, 2005 @11:53AM (#13043046) Homepage
      I switched back to Visual C++.

      And when a Microsoft product is the lesser of two evils, you know for sure that there's something fishy going on.
    • by bugnuts (94678) on Tuesday July 12, 2005 @12:01PM (#13043163) Journal
      You forgot this code at the bottom:

      push parent, @AMDsubpoena_list
    • Seriously, if you've still got the documentation, send that to AMD's legal team.

      That's a clear instance of them using their monopoly power to damage AMD's reputation with a developer (you).

      This *exactly* the sort of evidence they will be using to build their case.
    • by bitplayer (236632) on Tuesday July 12, 2005 @12:13PM (#13043327) Homepage
      While the focus of these threads is Intel vs. AMD competition, I think that it is worth pointing out that Intel is also crippling (or, at least, "not improving") the performance of their own PIII processors. For what reason would anyone do that, other than an desire to sell more P4 processors when a PIII processor might suffice?
    • by spworley (121031) on Tuesday July 12, 2005 @01:09PM (#13044057)
      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 [intel.com]

      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
  • by Anonymous Coward on Tuesday July 12, 2005 @11:45AM (#13042942)
    In version 1.0 of my software, I always throw in some loops that just count to a million to throw in some delays. That way you can include "optimization" as a deliverable for version 2.0.

    profit!
  • by Jarnis (266190) on Tuesday July 12, 2005 @11:49AM (#13042994)
    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 [theinquirer.net]

    They probably were hunting for some documents related to alleged antitrust violations - nice free additional ammo for AMD and their case, methinks...
  • by cluge (114877) on Tuesday July 12, 2005 @11:50AM (#13043006) Homepage
    Lets see, if one looks at almost ANY software license what does one see? "This may not be suitable for blah blah blah blah we disclaimed any liability for damages.". Ever since http://www.constructionweblinks.com/Resources/Indu stry_Reports__Newsletters/Sept_18_2000/defective_s oftware.htm [slashdot.org]">
    M.A. Mortenson Co., Inc. v. Timberline Software Corp. the courts have held that if you accept the license, it's not their fault. Even if they knowingly produce a faulty product.

    Is it dirty pool - sure is. Is it illegal? That remains to be seen. AMD most certainly has a firm ground to stand on when it comes to antitrust and Intel.

  • I think (Score:3, Funny)

    by bperkins (12056) on Tuesday July 12, 2005 @11:51AM (#13043022) Homepage Journal
    Intel should get the death penalty.
  • by ylikone (589264) on Tuesday July 12, 2005 @11:51AM (#13043032) Homepage
    ...software. Something like this would never be implemented in an open source compiler. With open source, you know exactly what you get... with closed, you get what the owners want you to get, which will help their bottom line.
  • Relevant Section (Score:5, Informative)

    by Dakrin1 (220684) on Tuesday July 12, 2005 @12:02PM (#13043174)
    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.
  • by MatD (895409) on Tuesday July 12, 2005 @12:03PM (#13043193)
    I know how this can happen (and it has nothing to do with being evil).
    The engineers get the specs for the next version of the compiler. They also get a slew of bug reports from the last version. They have a short amount of time to impliment the new specs, and fix the bugs.
    The bug reports will be something like, "on AMD processors when doing a memcopy with optimization xyz turned on, the processors mispredicts half the time. This makes it very slow."
    The engineer in that case, turns the optimization off for that generated code, thereby 'fixing' the bug (but not really). It happens all the time.
    It's not a nefarious plot, it's the same time crunch issue that every software engineer has to deal with.
  • by tjstork (137384) <todd,bandrowsky&gmail,com> on Tuesday July 12, 2005 @12:10PM (#13043288) Homepage Journal
    Intel makes a compiler and a debugging aid for their chips. AMD should make one for theirs. It sucks to go to AMD's web page and they don't have nearly the developer resources that Intel has. 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.
    • by Anonymous Coward on Tuesday July 12, 2005 @12:51PM (#13043826)
      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.
  • by asdfasdfasdfasdf (211581) on Tuesday July 12, 2005 @12:14PM (#13043342)
    From TFA:


    As a result of Intel's coercion, the HP-AMD desktop
    offering was dead on arrival. HP ended up taking only 160,000 of the million microprocessors
    AMD offered
    • for free.


    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.

  • by digital photo (635872) on Tuesday July 12, 2005 @12:46PM (#13043755) Homepage Journal

    Look, the issue is this:

    • There are AMD processors that support MMX, SSE, SSE2 (Intel Processor extensions)
    • The Intel Compiler is a widely used one for a segment of developers.
    • The compiler should create code which will use any and all of Intel's own optimizations( MMX, SSE, SSE2 )
    • The compiler will do this for Intel Processors.
    • The compiler will not use those very same extensions/optimizations when it detects an AMD cpu.
    • Those extensions are implemented by AMD to INTEL's specifications(licensed from them).
    • The compiler SHOULD make use of them.
    • They are NOT AMD specific extensions/optimizations.
    • The allegation is that INTEL made their compiler to work properly when compiling for INTEL chips, but not use ANY optimization extensions(intel or otherwise) when it detects an AMD chip.

    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

  • Old news... (Score:5, Informative)

    by coats (1068) on Tuesday July 12, 2005 @12:56PM (#13043895) Homepage
    Within a month after the Opteron release, computer scientists at the Fraunhoffer Institute in Germany had a "perl" script that would modify Intel-compiler generated executables to bypass the "Genuine Intel" test embedded in the executables, and use the optimized code path.

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Working...