Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel's "cripple AMD" function

agner.org

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Intel's "cripple AMD" function

#61

Post by rdl »

netcan wrote: post #55
brk wrote: post #50

Earlier quoted context omitted.

Yes. It's fairly established that chasing down the lowest-price path usually doesn't make for a very stable business model in the manufacturing businesses. This is even more significant when the competitive options are significantly limited (eg: processors). In larger markets (eg: automobiles) there is more room for low-cost competitors to make some money, but they are not often powerhouses of the industry. If you ha…

Well, first you said companies not just manufacturing companies so I would have pointed to Wal Mart. But since you have limited the range it's more difficult because manufacturing companies are not as high profile as retailers. I will point to China as a whole as a contemporary example. Chinese companies have consistently beaten the previous generation's manufacturers by achieving lower costs. Anyway, since you say "…

Being a low cost producer is a great survival strategy, even for a new entrant. Walmart, Amazon, and PC vs. Minicomputer are good examples. You can either use your cost advantage to undercut prices profitably, or use your large margins to outspend on R&D, marketing, etc.

Selling at low prices given the same cost structure is not a good survival strategy. "We lose money on every unit but we'll make it up on volume!"

Re: Intel's "cripple AMD" function

#62

Post by djcapelis »

drewcrawford wrote: post #41
jimbokun wrote: post #36

Earlier quoted context omitted.

"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 s…

There 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…

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

While I'm all for letting engineers react to things progressively, that you were in position where a screw up could have shut down a fab as an intern is nothing short of terrifying to me.

Re: Intel's "cripple AMD" function

#63

Post by DarkShikari »

chancho wrote: post #57
jey wrote: post #32

Earlier quoted context omitted.

Really? 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_BLOCKTI…

What are some kinds (examples?) of code that you find ICC to compile better than GCC? Like, what's a typical loop that ICC can vectorize but GCC can't? I always have the damnedest time pinpointing when and where these optimizations fire and I've pretty much given up on the compiler when it comes to them. Rather I just develop code as normal and then when it's done find the top 3 or 4 functions in gprof (or Shark or w…

ICC's vectorization is nearly useless. I've run it on thousands of lines of basic DSP code and gotten almost nothing--at best a single bad autovectorization.

The reasons ICC are better are many but unrelated to vectorization: one optimization I noticed is that it will compile a set of code that depends heavily on aliasing concerns twice and branch to which code path depending on whether the relevant pointers alias or not. This branch is usually predictable, since the pointers in reality will probably never alias, but it has to abide by the C spec.

There's probably a few dozen more things like this that add up to make it a few percent better than GCC. Though GCC is so buggy and many of its heuristics (especially inlining and storing array/struct elements in registers) so utterly hackneyed that beating it is not extraordinarily difficult..

Re: Intel's "cripple AMD" function

#64

Post by djcapelis »

dbz wrote: post #24
jrockway wrote: post #13

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

That idea is flawed because putting that string will make it optimize for an Intel chip, which will be worse than optimizing for an AMD chip because even though the compiler chooses the worst "optimized" option, it is still optimizing FOR that chip. -> The AMD optimization is optimized -But the Intel optimization is extra optimized (but not optimized for AM- only for itself).

Yes and no. I'm fairly certain that often the optimizations will be better than the fallback codepath in practice. This is especially true if you note that this is defeating the check for the vendor id, not defeating a lot of the other checks the dispatcher does.

Re: Intel's "cripple AMD" function

#65

Post by djcapelis »

pwmanagerdied wrote: post #34
pbhjpbhj wrote: post #27

Earlier quoted context omitted.

That would be passing off / trademark infringement FWIW.

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

Well, 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."

Re: Intel's "cripple AMD" function

#66

Post by sandGorgon »

netcan wrote: post #55
brk wrote: post #50

Earlier quoted context omitted.

Yes. It's fairly established that chasing down the lowest-price path usually doesn't make for a very stable business model in the manufacturing businesses. This is even more significant when the competitive options are significantly limited (eg: processors). In larger markets (eg: automobiles) there is more room for low-cost competitors to make some money, but they are not often powerhouses of the industry. If you ha…

Well, first you said companies not just manufacturing companies so I would have pointed to Wal Mart. But since you have limited the range it's more difficult because manufacturing companies are not as high profile as retailers. I will point to China as a whole as a contemporary example. Chinese companies have consistently beaten the previous generation's manufacturers by achieving lower costs. Anyway, since you say "…

what about Honda vs.... I dont know.. Detroit ?

That is a good example of manufacturing companies winning on cost.

Re: Intel's "cripple AMD" function

#67

Post by kelnos »

Andys wrote: post #49
praptak wrote: post #29

Earlier quoted context omitted.

"Only" benchmarketing? If any published benchmarks are affected by this misfeature, it's pitchforks and torches for Intel.

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

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

Re: Intel's "cripple AMD" function

#68

Post by kelnos »

DarkShikari wrote: post #7
adame944 wrote: post #3

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

That isn't exactly how it works. The proper way to do it: if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1} if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2} [etc] The even better way to do it: if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1} if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2} if( CPU is Athlon 64 ) {disable some SSE2 functions} if( CPU is Pentium-M ) {disable all SSE2 functions} [etc] Intel's way of doing it: if( CPU is…

If you read the article, it looks like Intel's CPU-type dispatcher actually does it the second way (sorta; it appears to only check Intel CPU family IDs), but at the bottom of that list there's a big "if(CPU string is not "GenuineIntel") { disable everything and use crappy fallback code path }".

Re: Intel's "cripple AMD" function

#70

Post by notauser »

rythie wrote: post #69

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

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

Post reply on HN