5 ms·
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 f
by effie 7y ago
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.
- mlyle 7y agoIf you have crappy tooling, the software other people write -- in house or commercial software-- runs crappier on your hardware.
- dpacmittal 7y agoBut it's irrelevant if it works faster than intel
- hamandcheese 7y agoIt’s not irrelevant if Intel has tools to let you close that gap easily.
- jfkebwjsbx 7y agoTools can't close a gap of entire cores, much less twice or more of them.
- mlyle 7y agoExtreme 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...
- kohtatsu 7y agoIt'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.
- deleted 7y ago[deleted]
- oneplane 7y agoUnless 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'...
- mlyle 7y agoAn 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.
- jpalomaki 7y agoThis 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-Intel-Xeon-2175W-Python-numpy---MKL-vs-OpenBLAS-1560/ https://www.pugetsystems.com/labs/hpc/AMD-Ryzen-3900X-vs-Int...
- fluffy87 7y agoI 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.