9 ms·
Intel's "cripple AMD" function
- herf 17y agoWhen using IPP, I had to rewrite the CPU detector, even for new Intel chips as they came out. This code should be better...really it should just benchmark all the options and catch processor exceptions to pick a supported path. Instead, the idea is to do a static dispatch for 'known' chips, which is really bad. When the Core2Duo came out, the version of IPP we used reverted to basic MMX code instead of SSE2, about 2.5x slower. This is just bad code, and it's bad on Intel chips, not just AMD. Also there is the "optimized for benchmarking" piece. It's not always good to use all your cores for one job, for instance, but a lot of these libraries make the assumption that your CPU has nothing else to do.
- NathanKP 17y agoThis doesn't really make any sense. All you would need to do is compile the code on an Intel machine to get fast speed and then you can run it on an AMD machine. It shouldn't really cause any problems as long as developers build on genuine Intel machines. Of course that it irritating, but it shouldn't cause any slowdown on other machines.
- ShabbyDoo 17y agoI think the compiler generates code which checks processor type at runtime, not compile time. If the compiled code is running on an AMD processor, the "safe" version of the compiled code is chosen automagically.
- NathanKP 17y agoWouldn't that make the code twice as large?
- ShabbyDoo 17y agoPerhaps, but size doesn't really affect runtime performance that much, especially if most codepaths are never execute -- no processor cache churn because the unused paths are never executed. I don't really know anything about this compiler, so I'm certainly speculating. My assumption is that one writes some function foo() and the compiler prepends a dispatcher in front which forks (code paths, not processes) to one of N optimized but functionally equivalent codepaths based on the actual processor upon which the code runs.
- ars 17y agoSize does affect performance because of the cache. If the forks are inline, and the cache works in blocks, then you are wasting cache space for code that never runs. But considering it's intel I'm sure they thought of that.
- pmjordan 17y agoI suspect it patches a jumptable at initialisation time based on CPU type, and all the code used by one type of CPU is bunched close together. The unused code probably isn't even paged into physical RAM.
- DougBTX 17y agoCertainly. These are performance optimisations, they must measure results.
- barrkel 17y agoIt's pretty common for runtime libraries to optimize low-level routines like memcpy, math, etc. with multiple different paths chosen on the basis of CPU capability bits. It's not the whole code that's twice the size; it's small functions which are implemented 2 or 3 or 5 times depending on what features are available.
- adame944 17y agoBottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.
- nvoorhies 17y agoIn addition to just the question of what path is optimal, they'd have to keep track of all the bugs in AMD's, Cyrix's, Transmeta's, and other implementations which aren't the same as the bugs on Intel x86 chips. Falling back to a subset of the architecture that is more likely to produce the right behavior is the sane thing to do. e.g. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf http://www.amd.com/us-en/assets/content_type/white_papers_an... v. http://download.intel.com/design/processor/specupdt/320836.pdf http://download.intel.com/design/processor/specupdt/320836.p... - these aren't just a couple gotchas you can put on the back of an index card
- wtallis 17y agoHave you actually looked at the details of the AMD errata? I scanned through quite a few, and none of them looked at all relevant to whether a compiler should enable certain SIMD extensions. Also, for the bugs that do need workarounds, the fix is typically in the BIOS or kernel, not the compiler. Regardless of whatever bugs may or may not exist in AMD's chips, it is anti-competitive for Intel's compiler to refuse to enable SSEx extensions on AMD processors that claim compatibility, when the user has requested SSEx instructions to be used, unless Intel has specific knowledge that AMD has never produced a sufficiently bug-free implementation of SSEx.
- drewcrawford 17y agoI was an AMD intern responsible for writing the software that tests for those bugs (these are my views and not those of AMD). You're entirely on the mark--the bugs are generally not SSE-related, and are typically worked around at the BIOS level. In addition, these bugs aren't "bugs" in the software sense, but more in the engineering sense; running some specific set of 10 million instructions on 3% of the chips while holding at exactly 28 deg C flips a byte in the L2 cache or something. Not something that's easily reproducible. OP is also right insofar as there would probably be a few gotchas with weird software that would make some engineer somewhere scratch his head because his for loop returns too quickly every third Monday. That doesn't mean that it's fair for Intel to disable SSEx, but it is probably an accurate observation--AMD and Intel have different bugs.
- jrockway 17y agoSounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)
- pbhjpbhj 17y agoThat would be passing off / trademark infringement FWIW.
- pwmanagerdied 17y agoNo it wouldn't. All else aside, if this were the case every browser for the past decade would have been sued for including "Mozillla" and/or "MSIE" in their user-agent strings.
- dangrossman 17y agoChrome identifies itself as Safari, and we know how protective Apple is of its trademarks.
- djcapelis 17y agoWell, it's somewhat unclear since "GenuineIntel" and "Intel" are not quite the same. I'm betting a good lawyer could make the case that the first explicitly seeks to confuse the user and thus dilutes the trademark. It would be interesting to see this play out in court though. I wonder if the judge could actually tell them that by using their trademark in a technical sense like this, perhaps that would cause dilution itself. As always, with the law it's a bit more complex than it might seem. Also note that most browser UAs explicitly states "like X."
- pbhjpbhj 17y agoThe important point is whether the mark is being abused as a false indication of the origin of the goods. In the case of UA strings this is plainly not the case (now). Vendor IDs are still considered to be indicative of the vendor - such an objection could be avoided by a disclaimer but this may yet not be enough if vendor-id were the common method to determine origin. Of course their are rules against using as a TM something that is not indicative of origin (generic names of products &c.) and so if a name were needed for interoperability purposes then it could well be argued for free use. I perhaps trolled slightly. Mea culpa. As for Chrome browser identifying as Safari, I think not, what does Help > About say.
- rbanffy 17y agoIsn't this the textbook reason for using - and contributing to - open-source compilers and libraries?
- liuliu 17y agoand gcc is not that bad after all. I uses openmp to parallel my program on core i7 860 cpu which should support 8-threads. But using icc as compiler, it will only utilize 7 cores, and it does affect performance (about 10% slower (wall time) than gcc which uses 8 cores). I suspect that it has something to do with the dynamic linked openmp library for icc.
- jey 17y agoReally? I find Intel's compiler to outperform GCC on pretty much all of the numerical work I do. I build with "-O3 -xHost" and make use of OpenMP. Dynamic linking of the OpenMP library is almost certainly not the cause of the slowness you're observing. If you really want to force the Intel OpenMP runtime to use all 8 cores: export OMP_DYNAMIC=false export OMP_NUM_THREADS=8 export KMP_LIBRARY=throughput # "KMP_BLOCKTIME" is how long an idle worker thread # should enter a blocking wait for more work before # sleeping, in milliseconds. default value is 200ms export KMP_BLOCKTIME=1000 # following are needed if you use Intel MKL export MKL_DYNAMIC=false export MKL_NUM_THREADS=8 For more info: http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/optaps/common/optaps_par_var.htm http://software.intel.com/sites/products/documentation/hpc/c...
- deleted 17y ago[deleted]
- rbanffy 17y ago"I find Intel's compiler to outperform GCC on pretty much all of the numerical work I do." It's only a question of time. I suspect that if more companies decided to pool resources around GCC (or any other free C compiler, like pcc or clang), they will pretty much bury Intel. Intel is a chip company. The only conceivable reason for them to want to maintain a C compiler is to make a C compiler that's better than the competition on Intel processors and that sucks as much as possible on competing architectures. Icc is not a compiler. It's a sales tool.
- Andys 17y agoSensational headline: this article is only about the Intel C Compiler, which as far as I can see, is only used for benchmarketing and research purposes.
- scott_s 17y agoAs a systems researcher, I have often used the Intel C Compiler when I wanted to make the most fair comparison possible because it is generally accepted to produce the best code of x86 processors. With that background, I correctly guessed from the headline what the content of the article was.
- praptak 17y ago"Only" benchmarketing? If any published benchmarks are affected by this misfeature, it's pitchforks and torches for Intel.
- Andys 17y agoDoes it really come as news to anyone that if Intel wants to show their CPU in best light, they'll use their own compiler? Caveat emptor. The bulk of the x86 world uses Microsoft C++ or GCC - end of story.
- kelnos 17y agoI think the parent was talking more about third parties doing benchmarks. If someone (not Intel) uses benchmarking software compiled with ICC, it might report erroneously bad results on an AMD system.
- praptak 17y agoYup, that was my point. Also, 'caveat emptor' has limits - Intel should at least state that their compiler produces suboptimal code for their competitors' CPUs.
- zeugma 17y agoI disagree. ICC is often use to optimize heavy computation code. As it have a reputation of producing faster code.
- drewcrawford 17y agoI was an intern for AMD a few years ago (these are my views and not AMD's). I was pretty skeptical about AMD's antitrust claims against Intel until I went to work there. I'm as free market as they day is long, but there's a whole untold story of the evil things that go on in the back meeting rooms, even outside of sales, where most of the public lawsuit claims are/were. The thing to remember is that AMD is a small fraction of the size of Intel, and they have to cover the same market segments. If they try to specialize (say, servers, or notebooks), Intel will just sell that segment at a loss. AMD has to cover everything with only a fraction of the people to stay competitive, and it's really hard. Even while I was there, we had what I suspect (but have no proof) were incidents of people leaking product plans, roadmaps, etc. (but no IP) to Intel. It's sad, really.
- jimbokun 17y ago"Even while I was there, we had what I suspect (but have no proof) were incidents of people leaking product plans, roadmaps, etc. (but no IP) to Intel." I can't imagine Steve Jobs allowing this to happen at Apple. They have definitely caught people leaking things, and the consequences were swift and unpleasant for the leaker. Why can't AMD catch these people? Is there something preventing them from implementing the same kinds of measures to catch leakers as Apple? (Using Apple just as an example, of course. I'm sure there are other companies who find leakers and make an example of them through the legal system.)
- deleted 17y ago[deleted]
- drewcrawford 17y agoThere was one guy who was strung up as a leaker ten years ago. Don't remember his name, but it was a big deal. AMD's culture is just different than Apple's. For one, there are no "secret teams" like iPhone, iTablet, etc. (well, at least none that I knew about). For another, developers have real autonomy to make business decisions, something that would never happen at Apple. For instance, I, a lowly intern, redeployed software to the production line during an emergency. If something went wrong, chips would actually stop rolling out of the factory. I would imagine normal (non-senior) Apple engineers don't have that kind of autonomy. The other major difference, which perhaps you caught above, is that AMD actually manufactures their own stuff. So, not only are there US engineers, but engineers overseas in the plants that AMD owns, engineers in Dresden, etc. Not to say that foreign engineers are somehow bad, but it is a lot harder to control leaks when you have engineers working literally 24/7 all around the world. And at the scale that you're making your own stuff, there are just more people than there are at Apple, and things are way harder to control. It's like herding cats.
- wmf 17y agoHas anyone tried the Sun Studio compilers? They're free and supposed to be as good as Intel, but I've seen virtually no discussion of them.
- daeken 17y agoFor x86, they fall behind a bit. For x64, they're faster than ICC in general. Definitely worth a look if you don't mind going to OSol.
- jedbrown 17y agoMy experience on x64 has been that Sun is usually competitive with GCC/ICC, but not clearly better. Sun's C99 compiler does really atrocious things with SSE intrinsics, strange since their C++ compiler handles intrinsics almost as well as GCC/ICC. Note that they also work fine on Linux.
- sfg 17y agoI do not know much about processor benchmarking, but is it not a little weird that the bench markers use software that is not independent of the hardware they are testing? It seems like they are asking to be manipulated: why do they do this?
- wmf 17y agoThey think the software is processor-independent but it's really Intel-biased; that's the problem.
- rythie 17y agoNot only should they fix it, they should open source the code, so AMD can contribute. Intel often makes noises about open source, so they should put their money where there mouth is.
- notauser 17y agoCompiler discussion to one side for a minute... Intel does more than just make noises about open source. Their wifi and graphics chip set support has been excellent over the years. Prior to the recent changes at ATI they were pretty much the only company doing that.
- rythie 17y agoAgreed and it's good that they do that since I use their graphics and Wifi drivers on my Ubuntu Laptop. My point was if they are truly committed to open source they would do this too, they are after all a hardware company and should compete by making the best hardware.