Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD

[phoronix]

Phoronix: Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD

When writing about the Intel Jump Conditional Code (JCC) Erratum and how Intel is working to mitigate the performance hit of the CPU microcode update with patches to the GNU Assembler, there was some concern expressed by readers that it might hurt AMD performance. That does not appear to be the case...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-With-Intel-JCC-Assembler

[tildearrow]

Proof that AMD has already beaten Intel.

[Guest]

The idea that everyone will add arbitrary restrictions on how to generate machine code just to ensure certain Intel chips don't get a slight performace loss with patched microcode is insane. Even if it doesn't seem to affect performance much, it's just a backwards idea to take CPU bugs in some Intel chips as a reason to patch the toolchain.

[airminer]

The idea that everyone will add arbitrary restrictions on how to generate machine code just to ensure certain Intel chips don't get a slight performace loss with patched microcode is insane. Even if it doesn't seem to affect performance much, it's just a backwards idea to take CPU bugs in some Intel chips as a reason to patch the toolchain.

This mitigation is functionally a microarchitecture-specific optimisation, that does not seem to have adverse effects on microarchitectures that don't benefit from it. GCC is already full of these march specific optimisations, eg. see -march and -mtune.

[Linuxhippy]

Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD

Nonsense. They do not hurt in case you comple with Zen2 target, but almost all software is compiled/linked for generic x86_64 - where you have those stupid workarrounds resulting in non-optimal code for executed by all platforms, just to avoid bugs on the Intel models.

For Intel-CPUs enabling code-gen workarrounds has always been out of question, I wonder what would happen in case AMD would require such workarrounds one day - would distributions/compilers decide to penalize Intel CPUs in order to work arround issues on AMD ones? Monopoly works.

[N4CR]

Oh right, even though it's not much then why does the right hand side of the table shows a marked regression after the patch?
That's more than statistical error....

Intel dragging the ship down with it due to laziness aka plausibly deniable anti-competitive practices.
Guess in future you need to bench with the pre-patch version?

[log0]

Nonsense. They do not hurt in case you comple with Zen2 target, but almost all software is compiled/linked for generic x86_64 - where you have those stupid workarrounds resulting in non-optimal code for executed by all platforms, just to avoid bugs on the Intel models.

Where are your benchmarks showing it to be nonsense?

The benchmark in the article was compiled with -mtune=skylake btw.

[jrch2k8]

I'm so genuinely happy i took that Ryzen 5 2600 for 120$ and didn't brain fart and went with something from Intel, my poor Xeon E3 1231v3(office WS) is suffering enough as it is and ironically need less mitigations than Skylake++++++++++

[pyler]

Where are your benchmarks showing it to be nonsense?

The benchmark in the article was compiled with -mtune=skylake btw.

Majority of software is compiled WITHOUT -march.

They must patch generic codegen to protect against this bug (we dont know where the resulting binary will run) too - perf loss for all.

[rene]

This mitigation is functionally a microarchitecture-specific optimisation, that does not seem to have adverse effects on microarchitectures that don't benefit from it. GCC is already full of these march specific optimisations, eg. see -march and -mtune.

no, it is not an optimization, it is a workaround for a really silly bug. If all CPUs would be so buggy and each vendor would like to have such crappy (32 byte alignment seriously) workarounds in the assembler, gcc/binutils would barely be able to still generate code at all. IMHO such crippling workaround should not be added to the toolchain at all, and vendors fix this bugs in the CPUs and microcode themselves. Maybe better ramp up their QA efforts and btw. users should demanded fixed silicon.