Hacker News Reader

Comment by effie | Hacker News Reader

I doubt tooling is the problem that is slowing down AMD adoption. Compiler or special applications writers care about that. These are not the ones who pay AMD for their platform. It's the big businesses - most care about stability, predictability, reliability hence they stay with Intel. Those that are interested mostly in bang/buck, like Cloudflare, choose to go with AMD, tooling or no tooling. You don't need tooling to check that AMD is far more efficient now, you just do some basic load tests and the result is easy to understand.

View on HN

If you have crappy tooling, the software other people write -- in house or commercial software-- runs crappier on your hardware.

But it's irrelevant if it works faster than intel

It’s not irrelevant if Intel has tools to let you close that gap easily.

Tools can't close a gap of entire cores, much less twice or more of them.

It's a matter of principle.

Some people don't want cores that you can't gather insight into how you are spending/wasting their time.

I'm not a direct customer of Intel or AMD, but in general I would trade off clock speed/cores/cost for insight into what my software is doing.

Extreme example: MKL on AMD is 3x slower than on Intel. Meanwhile, if you lie to it and say you're an Intel part, MKL is 20% faster than Intel...

Unless you're doing low-level stuff no developer is going to be aware that this even exists, much less capable enough to use it. There are more 'programmers' than 'engineers'...

An extreme example of the tooling gap: MKL. Intel made MKL and used CPUID and instruction set optimizations in a non-conformant way that penalizes AMD; it's a fair bit faster than OpenBLAS on (to-date) dominant Intel hardware.

If you make CPUID lie to it that it's an Intel part, it'll use AVX2, and Threadripper parts will beat Xeon by a 20% margin. Otherwise it's 200%+ slower.

Meanwhile, MKL has been a fair bit faster than OpenBLAS, etc on Xeon ("pretend to be Intel" MKL and OpenBLAS are about the same speed on AMD), so all kinds of software is linked against Intel MKL.

When you have core libraries tuned for Intel, either because Intel makes them themselves or because the tooling for performance tuning on AMD hasn't been present, Intel has a software tuning advantage that helps hide AMD's current silicon performance advantage.

This just reminded me of some older article on Numpy performance on Intel vs AMD [1].

I’m not posting this to bash AMD. Just trying to make point that the software side can matter a lot and from end customer point-of-view this can make a huge difference.

[1] https://www.pugetsystems.com/labs/hpc/AMD-Ryzen-3900X-vs-Int...

I was just going to mention numpy, or.. libc.

Sure, if AMD hardware is much better than Intels, an unoptimized libc might run better there. That’s not the point.

The point is that a libc optimized for AMD could run much better than what it does today.

Improving the performance of low level libraries for Intel hardware is trivial because there are a lot of great tools that help you with that.

If I had to improve the performance of some library on AMD hardware, I would get some Intel hardware and tools, improve the performance for Intel, and then “hope” that this improves the performance for AMD as well.

Reply on news.ycombinator.com