Hacker News Reader

Comment by zepearl | Hacker News Reader

Is the "MKL" mentioned by the article referring to https://docs.anaconda.com/mkl-optimizations/ (or something similar)?

If yes, then there is apparently an active engagement by Intel (therefore involving people&money) and I don't see anything wrong if they optimize their code for their CPUs and then ignore other manufacturers (AMD) - mooost probably they just don't have a reason about why they should improve their competition + trying to do that anyway (without having full insight about the "foreign" multiple CPU architectures) might generate even worse performance which in turn would backfire (e.g. "aaahh Intel is sabotaging AMD CPUs").

So, personally I would have no problem if when using iMKL ("intel MKL") the code would run faster on Intel CPUs by default and being conservative on other CPUs - but if I would own an AMD CPU then I would expect AMD to implement some similar optimization for their own CPUs (aMKL?).

View on HN

what you are talking about isn’t the situation. they are intentionally detecting cpu features wrong so as to not use features amd cpus have. nobody is expecting special amd optimization attention.

Ok, if it's like that ("intentionally detecting cpu features wrong") then I would agree.

Can a "CPU feature" (e.g. sse2, avx, aes, etc...) be implemented the same way between different architectures?

(Until someone has a more detailed answer) Both Intel and AMD are on the same X86 architecture, and sse2 etc are just extensions of the X86 architecture, u can check which feature flags a CPU has

And the call/use of these features is the same for AMD or Intel

They explicitly look for the "GenuineIntel" product string and then basically disable all the efficient code paths if it isn't found, totally against their own advice for ISA extension detection [1].

https://www.agner.org/optimize/blog/read.php?i=49

I'm curious if AMD could produce an internal engineering sample that simply copies all the relevant product strings from the competing vendor. They could check for statistically relevant performance discrepancies from just that modification.

don't need to make samples, you can fake the identifiers with virtualization and measure the delta.

But that has virtualization overhead. You don't want to measure that/risk being accused of measuring that.

Run both processes in a virtual environment then. Hell, that's where a lot of machines are running anyway. At least in server environments.

Also the overhead these days is pretty marginal, been running macos on an amd CPU emulating a Pentium(since macos also looked for Intel) and it beat all Mac pros of that time in cinebench etc

Sounds like user-agent strings all over again...

yes :) RDRAND is implemented differently

> they just don't have a reason about why they should improve their competition

I don't think this is quite true.

While their compiler team does care a lot about benchmarks, ultimately, they sell compilers. Some users won't use their compilers if they are too bad at running code on AMD's CPUs: often times 95th percentile performance is more important than median or mean.

Mmmhh, I have doubts about this - e.g. that their business that sells compilers isn't as important as the one that sells CPUs. There would be of course an indirect long-term effect etc... .

Their compiler is to sell their own chips. They lost a FTC case about this, and their solution was to add smallprint that said when running compiled code on non Intel CPU's it "may" not perform as well.

There are ways to patch ICC produced binaries to disable this genuineintel patch.

https://www.ftc.gov/news-events/press-releases/2010/08/ftc-s...

Reply on news.ycombinator.com