Intel's “Cripple AMD” Function (2019)
1–10 of 111 posts
Re: Intel's “Cripple AMD” Function (2019)
#2Huh I had wondered why I saw so many Python packages blacklist MKL now I know why.
Re: Intel's “Cripple AMD” Function (2019)
#3This 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.
Re: Intel's “Cripple AMD” Function (2019)
#4This 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.
Re: Intel's “Cripple AMD” Function (2019)
#5So 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.
Re: Intel's “Cripple AMD” Function (2019)
#6Huh 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.
Re: Intel's “Cripple AMD” Function (2019)
#7So 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.
Re: Intel's “Cripple AMD” Function (2019)
#8Last time this came up on Hacker News I discovered SolidWorks 2021 was using an older MKL library that supports the MKL_DEBUG_CPU_TYPE=5 environment variable. I'm on an AMD cpu and measured a small solidworks fps and rebuild time improvement with the flag enabled
Re: Intel's “Cripple AMD” Function (2019)
#9This 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.
At the firmware / driver level, fully open specifications for high performance hardware is an impossible dream.
At best, detailed documentation is a lower priority item below "make it work" and "increase performance".
At worst, it requires exposing trade secrets.
Edit: It'd probably be more productive for everyone if we set incentives and work such that the goal we want (compilers that produce code that runs optimally on Intel, AMD, and other architectures) isn't contingent on Intel writing them for non-Intel architectures. (Said somewhat curmudgeonly, because everyone complains about things like this, but also doesn't really how insanely hard and frustratingly edge-case-ridden compiler work is)
Re: Intel's “Cripple AMD” Function (2019)
#10So 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.
There are 2020 updates around MKL (But you may be correct that that content is about 2019 MKL optimizations).
At any rate though, based on Intel's track record I think this content is still relevant and of value to engineers who don't have domain knowledge in compilers or work downstream.