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

Intel's "cripple AMD" function (2009)

agner.org

Post reply on HN
Print view View original

91–100 of 131 posts

Re: Intel's "cripple AMD" function (2009)

#91

Post by corresation »

nitrogen wrote: post #63
corresation wrote: post #62

Earlier quoted context omitted.

I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general w…

1. Old versions of icc ran well on AMD. 2. New icc version adds check for "GenuineIntel". 3. New icc version now runs slowly on AMD.

This, like almost every counter point I've faced thus far, is simply wrong. It is manufactured reality.

ICC 8 added auto-vectorization. It, the very first auto-vectorization version, added the "GenuineIntel" branch for such vectorized code, because despite all of the fiction stated otherwise, vectorizing is actually a very hard task (hence why Intel maintains such a lead, and people are still griping about this 9 years after it came about).

I am hardly standing up for Intel, but this is Reddit-level conversation, where people simply say what they hope is true.

Re: Intel's "cripple AMD" function (2009)

#92

Post by Spooky23 »

aeonsky wrote: post #28
freehunter wrote: post #26

Earlier quoted context omitted.

Intel is the market leader by a good margin, and in the past has been known to use unfair tactics to keep other players out of the market. AMD has been in a lot of lawsuits with Intel due to this. In this case, it's not just that Intel isn't playing nice with AMD, it's that they're specifically using poor optimizations during compile if you're not using an Intel processor. That's not by accident, that's done on purpo…

I am usually not a free market extremist, but if Intel makes an excellent software product after years and millions of dollars in R&D, and make it only work for certain platforms, power to them.

You cannot give these companies an inch with stuff like this. In 2014, we're spoiled and for the most part don't realize that our network providers aren't the only potential toll keepers nickel and dimeing us.

I don't know if you are familiar with mainframe or similar computing technologies. When you buy an IBM mainframe (or Power unix box to a lesser extent), you're essentially metered by a CPU budget. You're not permitted to use the full capacity of your system unless you pay.

This case is a little different, but the point stands. Companies should not be allowed to sabotage the competition or hobble the ability of a device capable of doing a task from doing it. The free market works when the stakeholders don't cheat.

Re: Intel's "cripple AMD" function (2009)

#93

Post by jrockway »

If I were AMD, I'd just start calling my processor GenuineIntel. (Or maybe make it user programmable, and then absolve myself of any knowledge of what users are setting it to.) When the judge asks why, I'd say because those are the magic words to make certain binaries run faster, and I wanted to run a viable processor business.

This is not an acceptable use of trademarks.

Re: Intel's "cripple AMD" function (2009)

#94

Post by pjmlp »

corresation wrote: post #34
freehunter wrote: post #26

Earlier quoted context omitted.

Intel is the market leader by a good margin, and in the past has been known to use unfair tactics to keep other players out of the market. AMD has been in a lot of lawsuits with Intel due to this. In this case, it's not just that Intel isn't playing nice with AMD, it's that they're specifically using poor optimizations during compile if you're not using an Intel processor. That's not by accident, that's done on purpo…

Intel is not the market leader in compilers, however: It is somewhat rare to come across teams using the Intel compiler, and they tend to be in niche modeling/simulation or financial realms, more often than not with the sort of code that you compile for a specific piece of deployment hardware, compiling again when you move it to something different. Intel makes the ICC seemingly to try to encourage the adoption of ne…

The gaming industry does use it quite often. It is the Watcom compiler of the modern times.

Re: Intel's "cripple AMD" function (2009)

#95

Post by ibrahima »

happycube wrote: post #9

At this point, does intel need that function to make AMD's CPU cores look bad?

The thing that's sad is that if Intel hadn't taken so many unethical approaches to keeping AMD down when it actually was competitive with Intel on performance, the market could look totally different today. Back in the Athlon XP and early Athlon 64 days AMD was routinely ahead in benchmarks as well as power consumption, while P4 blustered along with higher and higher clock speeds. If they had gotten the market share their performance "deserved" (in some abstract sense, of course), they could have put more money into R&D and developed better follow on products. Instead, their market share grew only slowly, and eventually when Intel got back to improving performance AMD just fell behind and never recovered.

Intel's engineering prowess has to be respected, but how they got there by abusing their market position is deplorable. At this point I don't think there is any rational reason to buy AMD at any price point, they've been dominated so hard. (Buying ATI may not have helped, but these days that's the only part of AMD that's even still competitive.)

Re: Intel's "cripple AMD" function (2009)

#96

Post by fzltrp »

jrockway wrote: post #93

If I were AMD, I'd just start calling my processor GenuineIntel. (Or maybe make it user programmable, and then absolve myself of any knowledge of what users are setting it to.) When the judge asks why, I'd say because those are the magic words to make certain binaries run faster, and I wanted to run a viable processor business. This is not an acceptable use of trademarks.

> This is not an acceptable use of trademarks.

But if you were Intel, would you have your engineers work on competitors' products to make sure they are well supported on your line of tools? Before making an answer, consider that the core implementation of AMD cpus differ significanrly from those of Intel: instruction timings are slightly different, whether you look at them individually or in groups. It's not just a matter of turning a switch to get optimal performances, and that's just the tip of the iceberg.

Now, from a business standpoint, I think it could make sense for them to make their compiler produce fast code for any chip, but the legal implications of having a conccurent's product burn because of code produced with your compiler might make you think twice before going that road. Intel probably chose the safe road for a reason. Also, note that the produced code isn't crippled (as in, it doesn't make AMD cpu execute endless loops, or produce wrong results more than Intel's ones), it just follow the safest path.

Re: Intel's "cripple AMD" function (2009)

#97

Post by hvidgaard »

fzltrp wrote: post #96
jrockway wrote: post #93

If I were AMD, I'd just start calling my processor GenuineIntel. (Or maybe make it user programmable, and then absolve myself of any knowledge of what users are setting it to.) When the judge asks why, I'd say because those are the magic words to make certain binaries run faster, and I wanted to run a viable processor business. This is not an acceptable use of trademarks.

> This is not an acceptable use of trademarks. But if you were Intel, would you have your engineers work on competitors' products to make sure they are well supported on your line of tools? Before making an answer, consider that the core implementation of AMD cpus differ significanrly from those of Intel: instruction timings are slightly different, whether you look at them individually or in groups. It's not just a m…

Add another flag to the compiler to produce code optimized code for any CPU with the warning that it's only been verified to work with Intel CPUs. With todays CPU I do not buy the "safest path" argument - perhaps I could accept that "we only default enable it for implementations we have verified in-house", which makes a lot of sense.

This sounds a lot more like Intel know they make the best compiler, and knowingly put non Intel CPUs at a disadvantage because it would seem that they have a faster CPU.

Re: Intel's "cripple AMD" function (2009)

#98

Post by dpe82 »

eridius wrote: post #82
nanidin wrote: post #77

Earlier quoted context omitted.

We provided build scripts and source. The extra credit was for fastest execution time. I assume you're payed based on final results, not based on source. Not so crazy of a concept - whoever delivered the best results got rewarded for it.

Sure, but if merely switching compilers produced a faster binary, then I would expect all programs to be compiled with the better-optimizing compiler. After all, it doesn't take any particular expertise to adjust the value of CC.

There's more to optimization than setting -O3. Learning how various compilers behave and how their optimization features interact with your code are valuable skills and may well have been within the scope of the course. Certainly worthy of extra credit.

Re: Intel's "cripple AMD" function (2009)

#99

Post by fest »

Isn't this crippling a compile-time thing?

Is there something in binary that executes best-performing instructions (as opposed to execute just the instructions compiled in) when it's being executed on a specific CPU? If so, how exactly does it work?

Re: Intel's "cripple AMD" function (2009)

#100

Post by yuhong »

salient wrote: post #35
wmf wrote: post #16

Earlier quoted context omitted.

You're talking about a company whose motto is "only the paranoid survive". Why win when you can utterly dominate?

I don't think that's been their motto since Otellini took over. Look where they are now in the mobile market. Otellini put the profitability of their Core chips above improving Atom in the first few years, even when it came to netbook performance, which was already terrible. Combined with the fact that they forced OEMs to not buy AMD alternatives during the same time, Otellini just didn't think it's necessary to impr…

I think he came from marketing. Remember the Intel 487SX?
Post reply on HN