Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

[ryao]

Seven more speculative execution vulnerabilities found. An absolute disaster for CPU design. I guess the answer is remove Hyper Threading from mainstream processors and bump up the core count and remove speculative decision making from the architecture and offset the losses with clock speed increases. 7 to 8 GHz would be good? I guess smarter and more efficient processor design means worse security.

Intel could bring back Itanium as the solution. It was designed to avoid speculative execution from the start.

[L_A_G]

Ouch... I thought that they had now gotten to the point where they improve performance by swapping out existing software fixes for ones that do the same job with less of a performance hit (like retpolines), but it would seem like I was wrong about this and Intel keeps taking a beating in these fixes.

I've already heard about how some particularly low margin cloud service providers finding that the combined performance impact of previous Spectre and Meltdown fixes have put them dangerously close or even on the wrong side of the break-even point and this doesn't exactly help in that regard. Even as someone who considers Intel the Monsanto of the semiconductor industry I do hope that fixes improving performance will be merged within the next few weeks.

Something that worries me personally is that AMD hasn't been invulnerable to Spectre either and you'd think that these fixes would to some extent at least also affect AMD hardware. Is AMD in the clear or is it just that they haven't yet merged the patches that enable this on AMD hardware, kind of like it was with some of the previous mitigations for speculative execution vulnerabilities? That would be genuinely nice to know.

[TemplarGR]

I wonder if Hyperthreading is still worth it? Would it be interesting to run a speed test with it disabled?

Hyperthreading was only really worth it when cpus were single/dual cores. From 4 cores and upwards the benefit is questionable and heavily dependent on workload. For 8 core cpus it begins to become irrelevant, at least on desktop systems, and when we go to 16 and 32 cores you might as well disable it for ensuring some better thermal performance to squeeze some better clocks on your cpu.

All hyperthreading does is spoofing a core to the OS as 2 "logical" cores and force-feed 2 threads on a single core, hoping that unused parts of the pipeline can complete more work per clock. This may, or may not improve performance. In some cases it can even lower performance. But if you have enough cores for your software it makes no sense to use HT. I can't see how someone with 8+ physical cores would really care for HT on a desktop pc.

[TemplarGR]

Ouch... I thought that they had now gotten to the point where they improve performance by swapping out existing software fixes for ones that do the same job with less of a performance hit (like retpolines), but it would seem like I was wrong about this and Intel keeps taking a beating in these fixes.

I've already heard about how some particularly low margin cloud service providers finding that the combined performance impact of previous Spectre and Meltdown fixes have put them dangerously close or even on the wrong side of the break-even point and this doesn't exactly help in that regard. Even as someone who considers Intel the Monsanto of the semiconductor industry I do hope that fixes improving performance will be merged within the next few weeks.

Something that worries me personally is that AMD hasn't been invulnerable to Spectre either and you'd think that these fixes would to some extent at least also affect AMD hardware. Is AMD in the clear or is it just that they haven't yet merged the patches that enable this on AMD hardware, kind of like it was with some of the previous mitigations for speculative execution vulnerabilities? That would be genuinely nice to know.

AMD is only *realistically* vulnerable to the milder Spectre v1 variant.

[mvaar]

how many more speedhacks there are in intel cpus that sacrifice security? it just never ends.

It is clear now that Intel never had a performance advantage over AMD- it was all marketing and sleight of hand. Some experts are saying they should even disable HT. That and applying meltdown patches brings Intel core performance on par with bull dozer ! And all the trillions that data centers have wasted on Intel's inferior "solutions" while running a far superior co AMD into the ground by actively avoiding it.

[TemplarGR]

I guess now we know that Intel was outperforming AMD by cheating.

They have lost in court for that. Compiler shenanigans and stuff...

[peppercats]

I stopped using Intel long ago due to its awful business practices. Just another reason to not use Intel hardware.

[TemplarGR]

Seven more speculative execution vulnerabilities found. An absolute disaster for CPU design. I guess the answer is remove Hyper Threading from mainstream processors and bump up the core count and remove speculative decision making from the architecture and offset the losses with clock speed increases. 7 to 8 GHz would be good? I guess smarter and more efficient processor design means worse security.

Even with removing HT (something they eventually will do, i was surprized Zen had SMT when they knew they would hit so many cores easily, i suppose they mostly added it for marketing purposes), they won't reach 7-8 ghz... But they should be able to increase clocks like 10% more than now. Which more than offsets any lost performance from HT.

Anyway, it looks like 7nm/7nm+/5nm are going to increase core counts significantly, so HT will lose most of its importance.

[davidbepo]

want your performance back? here is the magical "word": nospectre_v2
spectre is a lower security threat than meltdown and this level of performance degradation is absolutely unacceptable and the only logical choice is to disable the mitigation as ive already done

[ryao]

It looks like this should affect AMD hardware too:

https://lore.kernel.org/patchwork/patch/980017/

https://arstechnica.com/gadgets/2018...t-performance/

My guess is is that Michael is testing AMD hardware that lacks the microcode update that gives stibp support. AMD’s website says that he needs to update his BIOS to get it:

https://www.amd.com/en/corporate/security-updates