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

Intel's “Cripple AMD” Function (2019)

agner.org

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Intel's “Cripple AMD” Function (2019)

#31

Post by mhh__ »

stavros wrote: post #12
Kon-Peki wrote: post #3

This has been discussed on HN before. I don't condone Intel behavior, but let's be honest here: AMD underinvests in software and expects others to pick up the slack. That isn't acceptable.

What should they have done instead? Built a compiler with a "cripple Intel" function? So people would have to download the executable that's fastest on their CPU, even though they use the same instruction set? The issue here is that they used a slower code path even on CPUs that could run the faster one, just because they were made by a competitor. You say "AMD should have made their own compiler", but why? What else…

AMD's software offerings (e.g. look at uProf vs vTune) are functional at best. Intel's are much easier to use, have a lot more documentation, and actually make your life easier versus having basically just a firehose of data.

Re: Intel's “Cripple AMD” Function (2019)

#32

Post by colejohnson66 »

benbenolson wrote: post #16
stavros wrote: post #12

Earlier quoted context omitted.

What should they have done instead? Built a compiler with a "cripple Intel" function? So people would have to download the executable that's fastest on their CPU, even though they use the same instruction set? The issue here is that they used a slower code path even on CPUs that could run the faster one, just because they were made by a competitor. You say "AMD should have made their own compiler", but why? What else…

Very likely, this was not done intentionally. I think we can simply imagine a common scenario: some employee working for Company X, developing a compiler suite, and adding necessary optimizations for Company X's processors. Meanwhile, Company Y's processors don't get as much focus (perhaps due to the employee not knowing about Company Y's CPUIDs, supported optimizations for different models, etc.). Thus, Company Y's…

The thing is: the bits to check for SSE, SSE2, ..., AVX, AVX2, AVX-512? They're in the same spot on Intel and AMD CPUs. So you don't need to switch based on manufacturer. The fact that they force a `GenuineIntel` check makes it seems malicious to many.

Re: Intel's “Cripple AMD” Function (2019)

#33

Post by mhh__ »

amelius wrote: post #4
Kon-Peki wrote: post #3

This has been discussed on HN before. I don't condone Intel behavior, but let's be honest here: AMD underinvests in software and expects others to pick up the slack. That isn't acceptable.

I think it's great if a hardware company leaves the software for others. This leads to open specifications.

If Intel did that there probably wouldn't be a software suite at all for their processors.

Compare to vTune just about all open source profilers are either a bad joke or like programming in Basic in a C++ age.

Re: Intel's “Cripple AMD” Function (2019)

#34

Post by IntelThrowaway1 »

Kon-Peki wrote: post #3

This has been discussed on HN before. I don't condone Intel behavior, but let's be honest here: AMD underinvests in software and expects others to pick up the slack. That isn't acceptable.

The thing that gets me about Intel's culture, as someone who worked there, was that Intel as an organisation was completely unable to actually accept they'd done anything wrong. Ever.

There are lots of cases where Intel has either screwed up or done things that were unarguably anti-competitive. It happens at every company, I don't like Uber, but I'm not going to blame Uber today for the fuckery that Kalanick got up to.

In each case you could ask the Intel HR, or Intel senior management what they thought about it and it was never Intel's fault. The answers to any questions about this sort of stuff would be full of pettifogging, passsive voice, and legalese. The result was the internal culture was an extremely low trust environment since you knew people were willing to be transparantly intellectually dishonest to further their careers. I haven't been there since Gelsinger arrived but I hope that changes, I wonder how much it can change in the legal environment we're in.

Re: Intel's “Cripple AMD” Function (2019)

#36

Post by magila »

benbenolson wrote: post #16
stavros wrote: post #12

Earlier quoted context omitted.

What should they have done instead? Built a compiler with a "cripple Intel" function? So people would have to download the executable that's fastest on their CPU, even though they use the same instruction set? The issue here is that they used a slower code path even on CPUs that could run the faster one, just because they were made by a competitor. You say "AMD should have made their own compiler", but why? What else…

Very likely, this was not done intentionally. I think we can simply imagine a common scenario: some employee working for Company X, developing a compiler suite, and adding necessary optimizations for Company X's processors. Meanwhile, Company Y's processors don't get as much focus (perhaps due to the employee not knowing about Company Y's CPUIDs, supported optimizations for different models, etc.). Thus, Company Y's…

No, this was definitely intentional. Intel is doing extra work to gate features on the manufacturer ID when there are feature bits which exist specifically to signal support for those features (and these bits were defined by Intel themselves!).

If they had fixed the issue shortly after it was publicly disclosed it might have been unintentional, but this issue has been notorious for over a decade and they still refuse to remove the unnecessary checks. They know what they're doing.

Re: Intel's “Cripple AMD” Function (2019)

#37

Post by DiabloD3 »

benbenolson wrote: post #16
stavros wrote: post #12

Earlier quoted context omitted.

What should they have done instead? Built a compiler with a "cripple Intel" function? So people would have to download the executable that's fastest on their CPU, even though they use the same instruction set? The issue here is that they used a slower code path even on CPUs that could run the faster one, just because they were made by a competitor. You say "AMD should have made their own compiler", but why? What else…

Very likely, this was not done intentionally. I think we can simply imagine a common scenario: some employee working for Company X, developing a compiler suite, and adding necessary optimizations for Company X's processors. Meanwhile, Company Y's processors don't get as much focus (perhaps due to the employee not knowing about Company Y's CPUIDs, supported optimizations for different models, etc.). Thus, Company Y's…

Thats not how these CPUs work.

The CPUID instruction allows software to query the CPU on if an instruction set is supported. Code emitted by Intel's compiler would only query if the instruction set exists if the CPU is from Intel, instead of just always detecting.

AMD can choose to to implement (or not) any instruction set that Intel specifies, and Intel can choose to implement (or not) any instruction set AMD specifies, however, it would in 100% of cases be wrong to check who made the CPU instead of checking the implemented instruction set. AMD implements MMX, SSE1-4, AVX1 and 2. Any software compatible with these must work on AMD CPUs that also implement these instructions.

If AMD ever chooses to sue Intel over this (likely as a Sherman Act violation, same as the 2005 case), a court would likely side with AMD due to the aforementioned previous case: Intel has an established history of violating the law to further its own business interests.

Re: Intel's “Cripple AMD” Function (2019)

#38

Post by ReleaseCandidat »

not2b wrote: post #19
stavros wrote: post #12

Earlier quoted context omitted.

What should they have done instead? Built a compiler with a "cripple Intel" function? So people would have to download the executable that's fastest on their CPU, even though they use the same instruction set? The issue here is that they used a slower code path even on CPUs that could run the faster one, just because they were made by a competitor. You say "AMD should have made their own compiler", but why? What else…

AMD should concentrate on making LLVM and GCC work great on AMD processors, by contributing the needed code. They are already making some contributions but could be doing more, and they could be funding experts to work on that and giving those experts the information they need.

They do. Actually their own (LLVM based) compilers are about as fast as GCC and LLVM

https://www.phoronix.com/scan.php?page=article&item=aocc32-c...

Re: Intel's “Cripple AMD” Function (2019)

#39

Post by bri3d »

Kon-Peki wrote: post #3

This has been discussed on HN before. I don't condone Intel behavior, but let's be honest here: AMD underinvests in software and expects others to pick up the slack. That isn't acceptable.

I think it's more nuanced than that:

In the past, AMD just straight up had horrible software.

More recently, AMD have been investing more in open software, probably with the goal that indeed, a community form and they get "leverage" / ROI for their investment.

On the flip side, Intel invest heavily in high-quality but jealously guarded and closed source software.

With this nuance, I'm not so sure it's clear cut which one is "acceptable," and it's an interesting ethical question about Open Source and open-ness in general.

Re: Intel's “Cripple AMD” Function (2019)

#40

Post by bally0241 »

djmips wrote: post #22
benbenolson wrote: post #16

Earlier quoted context omitted.

Very likely, this was not done intentionally. I think we can simply imagine a common scenario: some employee working for Company X, developing a compiler suite, and adding necessary optimizations for Company X's processors. Meanwhile, Company Y's processors don't get as much focus (perhaps due to the employee not knowing about Company Y's CPUIDs, supported optimizations for different models, etc.). Thus, Company Y's…

I don't think you read the article. Go read it first before you make your hypothesis. If it was as easy to fix as using a environment variable (which no longer works) then it was done intentionally.

I don't think the fact that it can be enabled/disabled by environmental variable indicates malicious intent. It could be as simple as that Intel doesn't care to test there compiler optimizations on competitors' CPU's. If have to distribute two types of binaries (one which were optimized but could break, vs un-optimized and unlikely to break), I would default over to distributing the un-optimized version. Slow is better than broken.

I understand some end users may not be able to re-compile the application for there machines, but I wouldn't say its Intel's fault, but rather the distributors of that particular application. For example, if AMD users want Solidworks to run faster on their system, they should ask Dassault Systemes for AMD-optimized binaries, not the upstream compiler developers!

Anyways, for those compiling their own code, why would anyone expect an Intel compiler to produce equally optimized code for an AMD cpu? Just use gcc/clang or whatever AMD recommends.

Post reply on HN