AMD Developers Looking At GNU C Library Platform Optimizations For Zen

[darkbasic]

By the way, as Clear Linux makes heavy use of that functionality, I'd bet that AMD CPUs will see additional significant performance gains in some benchmarks. One user already reported: "I patched cpu-features.c to allow arch_kind_amd cpus to match the haswell platform definition and have been getting good very good performance results with the glibc-bench benchmarks as well as a haswell optimized openblas which in turn improved results for R and octave (on a znver2 cpu). It seems intel as already has done most of the hard work for amd here?"

Michael that would be a *VERY* interesting benchmark to do

[CochainComplex]

We finally need Zen Linux for the clear minds

[joebonrichie]

I've already enabled this at Solus by allowing zen cpu's to use /usr/lib64/haswell, with good results. i'm glad to see some upstream work on this!

It should be noted by default some glibc functions run worse with AVX2 but the Clear Linux guys figured it out (compile specific math ops with difference vector-widths)

Quick performance results that I've seen:-
Glibc benchmarks: https://openbenchmarking.org/result/...HU-GLIBCSOLU43
R benchmark took 13% less time to run by using avx2-glibc and avx2-openblas
GROMACS took 23% less time to run the water benchmark

Ideally as a maintainer i'd like to see a vendor-neutral generic avx2 path that can benefit both haswell+ and zen+. Shipping different solibs for haswell and zen is not worth it, in terms of compilation time, disk space and minimal performance difference most likely.

The biggest issue I can see facing is that intel and amd cpu's may prefer difference vector-widths (128 vs 256) for the same task. GCC isn't really smart enough to choose the best vector-width sometimes which can make performance worse than bog-standard SSE2.

[ddriver]

The biggest issue I can see facing is that intel and amd cpu's may prefer difference vector-widths (128 vs 256) for the same task. GCC isn't really smart enough to choose the best vector-width sometimes which can make performance worse than bog-standard SSE2.

AVX2 is 256bit. The size of the actual physical registers is irrelevant and completely transparent from the perspective of a software developer. It is not a concern how the underlying uarch handles the issued instructions, even zen 1 supports avx2 perfectly fine, even if the instructions take more cycles to complete.

[joebonrichie]

AVX2 is 256bit. The size of the actual physical registers is irrelevant and completely transparent from the perspective of a software developer. It is not a concern how the underlying uarch handles the issued instructions, even zen 1 supports avx2 perfectly fine, even if the instructions take more cycles to complete.

Regardless, you sometimes have to compile AVX2 code with -mperfer-vector-width=128 for the best performance. Similarly for AVX512-Skylake Clang and GCC(?) default to -mperfer-vector-width=256 due to the downclocking and increased heat output from the full 512 width leading to worse performance.

[gorgone]

as I was saying weeks ago
the current business areas allow AMD to make a real investment in software development for the first time
but I think it should also be supported individual showcase projects such as OBS or KDENLIVE
these are opensource "lighthouses" that many youtubers use for example

[GruenSein]

I find it a bit twisted to blame AMD for not optimizing the linux tool chain before Zen CPUs were released. I'd like to remind everyone of two things:

1. Before Zen, AMD was almost bankrupt losing enormous amounts of money each quarter. At the same time, they were basically not competing in the server- and HPC-field anymore, where Linux is the dominant OS. There was absolutely no reason to waste the few resources they had in this area. Exactly this is changing now, which I am happy to see.
2. When AMD wanted to get DC, which is now known as DAL, mainlined, they were held up for months because their working implementation was not generic enough. The maintainers correctly pointed out that their code was highly specific to their drivers with many abstractions which might hold back a wider adoption by other drivers and was in sharp contrast to the general coding style. Interestingly, this was no issue for Intel in this instance. Any maintainer could've asked them to implement a generic CPU capability detection. That obviously didn't happen.

What that means is: AMD is contributing to Linux as much as it makes economical sense to them. Nothing more can be expected.

[abott]

AMD became smarter. Just about time.

More like AMD finally has a fucking dollar to spend. What a stupid reply.

They were on the verge of bankruptcy and you want them to improve software? Your guidance would have killed them 2 years ago.

[ddriver]

I really don't get the "spoiled" mentality. Contributions are welcome, but it doesn't mean that's what you exclusively rely on. It is not only in the interest of amd but also in the interest of the product's developers that it runs optimally across all hardware.

I have several friends working in AAA game studios, and that's basically their rationale for not optimizing for radeon - "nvidia does our job for us and gives us trinkets, amd gives us nothing"...

[Volta]

More like AMD finally has a fucking dollar to spend. What a stupid reply.

They were on the verge of bankruptcy and you want them to improve software? Your guidance would have killed them 2 years ago.

If mesa drivers are more profitable than optimizing their CPUs then you're right. But guess what? No, you're not.