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

41–50 of 111 posts

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

#41

Post by bee_rider »

wyldfire wrote: post #14
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.

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

The expectation in the HPC community is that an interested vendor will provide their own BLAS/LAPACK implementation (MKL is a BLAS/LAPACK implementation, along with a bunch of other stuff), which is well-tuned for their hardware. These sort of libraries aren't just tuned for an architecture, they might be tuned for a given generation or even particular SKUs.

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

#42

Post by ReleaseCandidat »

mhh__ wrote: post #35

This could arguably dated 2009 as that is when it was originally discovered (approx.). https://www.agner.org/optimize/blog/read.php?i=49

It has been discovered before that, at least in 2005:

https://techreport.com/news/8547/does-intels-compiler-crippl...

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

#43

Post by salawat »

hpcjoe wrote: post #18
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 t…

You call Nvidia driver installation easy? Every bit of "ease" about that is hardly Nvidia's doing.

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

#44

Post by dodobirdlord »

sedatk wrote: post #24
amelius wrote: post #4

Earlier quoted context omitted.

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

No, just don't falsely market your product as fair or neutral.

It’s the Intel MKL, I don’t think Intel has ever even endorsed using it on other vendors CPUs, much less claimed that it is “fair” or “neutral”.

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

#45

Post by eatonphil »

Certified wrote: post #8

Last 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

The first comment seems to suggest that flag no longer works.

https://www.agner.org/forum/viewtopic.php?t=6#p82

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

#46

Post by ReleaseCandidat »

dodobirdlord wrote: post #44
sedatk wrote: post #24

Earlier quoted context omitted.

No, just don't falsely market your product as fair or neutral.

It’s the Intel MKL, I don’t think Intel has ever even endorsed using it on other vendors CPUs, much less claimed that it is “fair” or “neutral”.

Well:

    On November 12, 2009 AMD and Intel Corporation announced a comprehensive settlement agreement to end all outstanding legal disputes between the companies, including antitrust and patent cross license disputes. In addition to a payment of $1.25B that Intel made to AMD, Intel agreed to abide by an important set of ground rules that continue in effect until November 11, 2019. 

    Customers and Partners

    With respect to customers and partners, Intel must not:*
    [...]
    Intentionally include design/engineering elements in its products that artificially impair the performance of any AMD microprocessor.
https://www.amd.com/en/corporate/antitrust-ruling

I like that 'in effect until November 11, 2019.' part :D

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

#47

Post by wmf »

wyldfire wrote: post #14
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.

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

Each vendor. Intel BLAS (MKL) has Intel-specific optimizations and AMD BLAS has AMD-specific optimizations.

Intel is still acting in bad faith by allowing MKL to run in crippled mode on AMD. They should either let it use all available instructions or make it refuse to run.

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

#48

Post by Certified »

eatonphil wrote: post #45
Certified wrote: post #8

Last 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

The first comment seems to suggest that flag no longer works. https://www.agner.org/forum/viewtopic.php?t=6#p82

Multiple versions of MKL dlls exist in the install directory of Solidworks 2021. Indeed, the dlls supporting FloXpress and simulation seem to be the updated MKL version that no longer support the flag. However, the main executable only seems to call sldmkl_parts.dll. It appears to be MKL version 2018.1.156 that does support the flag

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

#49

Post by midjji »

bri3d wrote: post #39
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…

AMD still has horrible software, compare cuda to whatever crap AMD thinks you should use. Truth is its even hard to say what their alternative is, not to mention how horribly poorly they support what is, or at least should be their second if not most important/lucrative target.

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

#50

Post by bee_rider »

eatonphil wrote: post #45
Certified wrote: post #8

Last 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

The first comment seems to suggest that flag no longer works. https://www.agner.org/forum/viewtopic.php?t=6#p82

It would depend on the version of MKL. If Solidworks has (just for example) statically linked to or bundled in an old version of MKL, then it should work there, still.
Post reply on HN