LLVM Lands Very Basic Support For AMD Zen 3 CPUs

[phoronix]

Phoronix: LLVM Lands Very Basic Support For AMD Zen 3 CPUs

While AMD has landed Znver3 support in GNU Binutils, the company hasn't yet sent out patches for either the GCC or LLVM/Clang compilers in setting up the Zen 3 target with its new instructions or optimized scheduling model / cost table. But a basic implementation has been merged to LLVM for allowing "-march=znver3" based on the limited public details thus far...

http://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lands-Basic-Znver3

[sdack]

Most of Zen3's performance will come from the new cache design and increased clock speeds, which has only a small influence on the scheduling. And the instructions that have received changes in their cycle times might not all make a difference for the scheduling and the emitted code. Frankly, I doubt there will be a huge difference in the emitted code for Zen3 when compared to Zen2. So why get desperate over Zen3 support before these processor have been released yet?

[xnor]

@sdack: Because it will take a while until new upstream versions trickle down into distributions to the end users. In some cases this can take a year or longer, so the software and drivers should have been long released by the time the hardware is available.

But you're right about Zen2 vs Zen3 compiler optimization differences, so it doesn't matter that much in this case.

[sdack]

Because it will take a while until new upstream versions trickle down into distributions to the end users.

You wish! Compiler developers don't concern themselves with slow or ancient distros. It's a problem created by these distros and only for them to fix. There are distros that update rather quickly if you care to look for them.

[ms178]

You wish! Compiler developers don't concern themselves with slow or ancient distros. It's a problem created by these distros and only for them to fix. There are distros that update rather quickly if you care to look for them.

I assume most servers won't run those rolling-release distributions though.

It might also improve the value proposition for EPYC to have these compiler optimizations ready at launch, especially with product cycles of 12 - 18 months. It is rather unfortunate that the next hardware iteration is out before you see good support for the hardware you just bought (with an added bonus to get better performance later on, but the time you could have already used your hardware upto its full potential might be valuable, too).

[S.Pam]

Most of Zen3's performance will come from the new cache design and increased clock speeds,
...
doubt there will be a huge difference in the emitted code for Zen3 when compared to Zen2. So why get desperate over Zen3 support before these processor have been released yet?

Doesn't compilers use information about cache-sizes to determine how best to optimise code paths? Simple case is unroll loops. With much larger caches, the optimisations could be better and more efficient.

[vladpetric]

Doesn't compilers use information about cache-sizes to determine how best to optimise code paths? Simple case is unroll loops. With much larger caches, the optimisations could be better and more efficient.

Not really.

I mean compilers do use heuristics which can be tuned per architecture (march). But those heuristics are just that - you could actually give them "better" information and sometimes they will produce worse code. The compiler doesn't manage the cache (nor should it, IMO). Having too much loop unrolling can increase instruction cache pressure, indeed. But loop unrolling is not guided by the size of the L3 cache.

I wish Michael would evaluate the effect of -march/-mtune in the absence of code that is specific to the architecture (essentially, hand-written assembly for that precise processor). Personally, I think the effect is minimal (like 1-2%). Do note that if there's handwritten assembly that is turned on/off by the -march flag, the effect can be pretty large.

[CommunityMember]

I assume most servers won't run those rolling-release distributions though.

For leading companies, even if they do not build their own kernel (and for the big players, they may very well build their own kernel with profile based tuning), the servers are likely just running various vm instances, or orchestration services and containers built by the developers who use the best tools available, so it does not entirely matter what distribution the server runs to gain the benefits of the latest technologies.