notoperableDepends on your use case +/- its easy to validate by running a kernel mainline compile with mitigations=off and without in the kernel command line on boot

First, nobody said about anything being slower over time.

notoperableminus 20% of performance mitigations tax that was never refunded

notoperableSecondly - how can this be on me, enlighten me how you came to this conclusion

Because it does not happen on newer CPUs, or even many older ones with an updated OS. You need to go more than a decade back in time to get hit by ~20% mitigations.

notoperablelastly you might be using keywords like Specre or Meltdown to sometihng else then processor vulnebarilities - otherwise you wouldnt use it in context of raptor lake

The mitigations you speak of were for Spectre and Meltdown vulnerabilities. It had a noticeable impact on processors that precede the Haswell architecture (so older than 13 years old at this point), while anything Haswell and newer already had a way to deal with these things faster. Newer CPU models work in a different way at the hardware level, and as such "mitigations" do not apply as the hardware is not affected by the problem. If you are running anything newer than Coffee Lake, you're completely in the clear.

InSpectre, which is the app that displays whether your computer is vulnerable and if it can be updated, has not been updated for over 8 years at this point. And Intel's guidance on mitigation is equally old, in fact, not even hosted on their site anymore. Here:

web.archive.org/web/20180406104623/https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf

Moreover, if you install any version of Windows released since mid-2018 on affected hardware, you're already patched.

Dr. DroThe mitigations you speak of were for Spectre and Meltdown vulnerabilities.

You’re wasting your typing. He’s been posting the same thing for years now. You’ll never convince him, his hatred is too strong.

I don't do kernel compilations on Windows lol

Dr. DroBecause it does not happen on newer CPUs, or even many older ones with an updated OS. You need to go more than a decade back in time to get hit by ~20% mitigations

What you are saying is nonsensical, has not answered my question: how is that is on me- since it hardly can be - only thing you can do is add more nonsense
or admit that you might have miss interpreted the meaning or something.

You can read what mitigations do to performance to Linux compile times for example on phoronix.com, imagine there is a world in which operating systems is
not equal to Windows and a control panel.

Humor me, have you actually disabled mitigations on your Windows (the version does not matter if you know how to disable those btw.) to measure the difference?
It seems you repeat a Spectre and Meltdown as 2 CVE's (and those first published contains already 3 not 2 btw)- a common mistake - sidechannels attacks grew to a
much bigger pool then those you stick to having no idea what it does or mean obviously.

RTFM || GTFO - in short

notoperableI don't do kernel compilations on Windows lol


What you are saying is nonsensical, has not answered my question: how is that is on me- since it hardly can be - only thing you can do is add more nonsense
or admit that you might have miss interpreted the meaning or something.

You can read what mitigations do to performance to Linux compile times for example on phoronix.com, imagine there is a world in which operating systems is
not equal to Windows and a control panel.

Humor me, have you actually disabled mitigations on your Windows (the version does not matter if you know how to disable those btw.) to measure the difference?
It seems you repeat a Spectre and Meltdown as 2 CVE's (and those first published contains already 3 not 2 btw)- a common mistake - sidechannels attacks grew to a
much bigger pool then those you stick to having no idea what it does or mean obviously.

RTFM || GTFO - in short

What part of IT DOES NOT AFFECT NEW HARDWARE do you fail to understand? The architectural error that led to these exploits has long since been FIXED.

This is clearly the hill you chose to die on, but please kindly stop intentionally spreading misinformation and making up wild stories

Dr. DroWhat part of IT DOES NOT AFFECT NEW HARDWARE do you fail to understand? The architectural error that led to these exploits has long since been FIXED.

This is clearly the hill you chose to die on, but please kindly stop intentionally spreading misinformation and making up wild stories

Could you then quote and unmisinform me and point exactly where that happens - and with those intentions of mine behind it :-)
Distraction rhetoric from the amateur hour guide how to navigate a discussion wont do.

notoperableCould you then quote and unmisinform me and point exactly where that happens - and with those intentions of mine behind it :-)
Distraction rhetoric from the amateur hour guide how to navigate a discussion wont do.

www.phoronix.com/review/intel-panther-lake-mitigations

Impact of mitigations for most things in modern platforms is very small or non existant, in some very specific cases "mitigations=off" option in modern platforms can be worse.

It's also worth noting that if you care about security and mitigation impact, these modern Intel consumer CPUs not having SMT support is a good thing in that regard then, as one is able to just skip a lot of speculative attacks thanks to not having SMT.

Rulumiwww.phoronix.com/review/intel-panther-lake-mitigations

Impact of mitigations for most things in modern platforms is very small or non existant, in some very specific cases "mitigations=off" option in modern platforms can be worse.

It's also worth noting that if you care about security and mitigation impact, these modern Intel consumer CPUs not having SMT support is a good thing in that regard then, as one is able to just skip a lot of speculative attacks thanks to not having SMT.

I never said anything about security - i said 20% performance tax on compile time with and without mitigations=off compare. Thanks for showing phoronix table, I mentioned it above.
Since you got some understanding- to see what I mean, humor me and what is your guess what happens to those benchmark results if you cut off the pre-initramfs microcode (the entry that gets inserted before initrd) update, its a default in most distros. Also you campre apples to oranges if you dont create the same baseline. Also what do you think happens to performance when you apply the same to Windows, you can go even further and take a gcc from the time raptorlake was launched and not 5 years after the mitigation cost was optimized away.