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

11–20 of 111 posts

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

#11

Post by Anunayj »

shrx wrote: post #7
mechanical_bear wrote: post #5

So it appears not only is this posting from 2019, but the most recent information they reference is 2010. This seems to be no longer relevant? I’d love it if submissions on HN had a small blurb from the author explaining why their submission is interesting/relevant.

It certainly is still relevant. Please read the article (and the 2020 update below) before commenting on it.

yup, infact recently MATLAB applied a fix to this for their software [1]

[1] https://www.extremetech.com/computing/308501-crippled-no-lon...

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

#12

Post by stavros »

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 should they have made? An OS? An office suite? Why?

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

#13

Post by monocasa »

dbcurtis wrote: post #6
holdenk wrote: post #2

Huh I had wondered why I saw so many Python packages blacklist MKL now I know why.

The philosophy behind MKL is that each CPU vendor provides an MKL for their CPU. If you expect to mix and match MKLs and CPUs, you don’t understand the goals of MKL.

Are there any implementations of MKL other than Intel's?

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

#14

Post by wyldfire »

dbcurtis wrote: post #6
holdenk wrote: post #2

Huh I had wondered why I saw so many Python packages blacklist MKL now I know why.

The philosophy behind MKL is that each CPU vendor provides an MKL for their CPU. If you expect to mix and match MKLs and CPUs, you don’t understand the goals of MKL.

Each CPU vendor or each CPU architecture? (genuinely asking, I don't know how it's intended)

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

#15

Post by ReleaseCandidat »

dbcurtis wrote: post #6
holdenk wrote: post #2

Huh I had wondered why I saw so many Python packages blacklist MKL now I know why.

The philosophy behind MKL is that each CPU vendor provides an MKL for their CPU. If you expect to mix and match MKLs and CPUs, you don’t understand the goals of MKL.

That would be 'each CPU vendor provides an optimized BLAS library for their CPU'. The problem is that Intel's MKL is more than just BLAS.

But AMD does have its own optimized libraries:

https://developer.amd.com/amd-aocl/

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

#16

Post by benbenolson »

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…

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 processors don't run as quickly with this particular library.

Why does this have to be malicious intent? Surely it's not surprising to you that Company X's software executes quicker on Company X's processors: I should hope that it does! The same would hold true if Company Y were to develop a compiler; unique features of their processors (and perhaps not Company X's) should be used to their fullest extent.

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

#17

Post by ReleaseCandidat »

monocasa wrote: post #13
dbcurtis wrote: post #6

Earlier quoted context omitted.

The philosophy behind MKL is that each CPU vendor provides an MKL for their CPU. If you expect to mix and match MKLs and CPUs, you don’t understand the goals of MKL.

Are there any implementations of MKL other than Intel's?

No. There are AMD's AOCL and Apple's 'Accelerate', but of subsets of the MKL only AFAIK.

https://developer.amd.com/amd-aocl/ https://developer.apple.com/documentation/accelerate

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

#18

Post by hpcjoe »

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.

AMD[1], NVidia[2] do "make" their own compilers. AMD is notorious for a "build it and they will come" mentality. Despite the fact that this hasn't worked. AMD needs to make it easy to adopt their hardware, and the way this is done is with software.

When they finally get to the point that their driver/libs are as easy to install as Nvidia's , it might be too late. I've argued this with AMD folks before.

The barriers to adoption need to be low. Friction needs to be low. They need to target ubiquity[3].

[1] https://developer.amd.com/amd-aocc/

[2] https://developer.nvidia.com/nvidia-hpc-sdk-downloads

[3] https://blog.scalability.org/2008/02/target-ubiquity-a-busin...

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

#19

Post by not2b »

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

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

#20

Post by MereInterest »

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.

There's a variety of options that are available here, and I don't buy the argument that AMD's behavior is automatically unethical.

A. Company makes and sells hardware, and offers no software.

B. Company makes and sells uniquely featured hardware, and offers software that uses those unique features.

C. Company makes and sells hardware that adheres to an industry standard, and offers software that targets hardware adhering to that standard.

D. Company makes and sells hardware that adheres to an industry standard, then uses their position in related markets to give themselves an unfair advantage in the hardware market.

Of these, options A, B, and C are all acceptable options. AMD has traditionally chosen option A, which is a perfectly reasonable option. There's no reason that a company is obligated to participate in a complementary market. Option D is the only clearly unethical option.

Post reply on HN