Benchmarks Of JCC Erratum: A New Intel CPU Bug With Performance Implications On Skylake Through Cascade Lake

[starshipeleven]

So now we get another round of "fixes" to fsck core kernel stuff for years to come.
Awesome. Just awesome..

This is just an optional codepath, nothing is fucked up, calm down

[starshipeleven]

What a load of crap.

This is not some obscure bug that might happen under some circumstances.
This affects fundamental functionality of the product and if it can't be addressed by a patch, product should be replaced.

I'd like to see some more "enlightened" countries like say germany actually mandate that by court, while I'm sure most other countries won't care.

[archsway]

This is just an optional codepath, nothing is fucked up, calm down

Ah, so you can just disable it and the kernel will re-assemble and re-link all your programs for you?

Maybe for JITs it will be optional, but not everyone runs all their programs using wasm yet.

[starshipeleven]

Ah, so you can just disable it and the kernel will re-assemble and re-link all your programs for you?

Maybe for JITs it will be optional, but not everyone runs all their programs using wasm yet.

WTF are you talking about? This "fix" is in GCC compiler, not linux kernel.

[archsway]

WTF are you talking about? This "fix" is in GCC compiler, not linux kernel.

What are you talking about?

You're the one replying to a comment about "core kernel stuff" talking about an "optional" codepath.

Or did you mean that the optional codepath was in the assembler?

[starshipeleven]

did you mean that the optional codepath was in the assembler?

Yes the optional codepath is in the compiler. They aren't changing the compiler to create different binaries for other archs and this is just a compiler option.

As for the guy talking about kernel, oh whatever.

EDIT: aaand I'm right https://www.phoronix.com/scan.php?pa...er-Patches-JCC it's enabled with -mbranches-within-32B-boundaries

[Isedonde]

It would be interesting to see what the performance impact for binaries produced by the updated toolchain when using an AMD CPU looks like. Distros will likely use the updated toolchain to compile their packages, since they want performance for Intel users to be good, but how will this (needlessly) impact AMD users? Maybe it's time for distros to start preparing actual "amd64" and separate "intel-amd64" packages, where the amd64 packages have no Intel workarounds applied. Okay this is probably overkill. :-)

[RussianNeuroMancer]

......not to start a fanboy war but I think I won't be buying anymore intels from now on. I'm still on my 5yo Haswell PC

So Spectre/Meltdown/friends somehow wasn't enough for you year ago?

[yurikoles]

Michael

cross a 32-byte boundary or where they end on a 32-bit boundary

[Guest]

I am mystified by how a bug in conditional branch instructions could have been overlooked for 5 years in what has to be the most widely-deployed CPU design in the world. Surely that's among the most common classes of instructions in any program? I can't imagine how fixing something that seems to be astronomically improbable would be worth the performance hit, vs just patching the affected applications.

Considering that there's plenty of proprietary software out there that will never get recompiled to account for this issue, the patch is necessary. Try paying attention to what you're reading next time.