4 ms·

yeah this just makes me wanna see real world numbers on the slowdown, cuz honestly all these microcode fixes feel like trading off years of speed for maybe a l

yeah this just makes me wanna see real world numbers on the slowdown, cuz honestly all these microcode fixes feel like trading off years of speed for maybe a little more peace of mind - you ever think well actually move off this cycle or is it just here to stay?

myself248 1y ago
I'd love to see a graph showing mitigations=off vs mitigations=on speed gains over the years. It feels like most of the new tricks have had vulnerabilities of some sort, which eat up some or most of their gains. Of course at launch, the vulns haven't been found yet, so the performance uplift claims are all fluff based on the reckless actions of an unprotected trick. By the time the skeletons have come out of the closet, the release hype cycle is far in the past, and only a few nerd blogs will cover the corresponding performance hit. Lather, rinse, repeat for the next launch. New tricks, new reckless performance gains, big uplift numbers, hope it takes a little while before anybody points out the holes in the emperor's clothes. But at the end of the day, the actual performance progress over time is, I suspect, dramatically slower than what the naïve summation of individual launch-day claims would suggest. To your second point: I think it's here to stay as long as we allow someone else's code (via js, webassembly, and their ilk) to run on our processors as a matter of course. A rethink of the entire modern web, back to a simpler markup language that isn't Turing-complete and can't leak data back to the attacker's server, would be needed before we could turn the mitigations off and enjoy the performance we were promised. But of course, if we get rid of the modern web as we know it, we probably don't need all that performance anyway. An old BlueWave/QWK mailer consumes 10,000x less resources than a Gmail tab, you know?

myself248 1y ago

I'd love to see a graph showing mitigations=off vs mitigations=on speed gains over the years. It feels like most of the new tricks have had vulnerabilities of some sort, which eat up some or most of their gains. Of course at launch, the vulns haven't been found yet, so the performance uplift claims are all fluff based on the reckless actions of an unprotected trick. By the time the skeletons have come out of the closet, the release hype cycle is far in the past, and only a few nerd blogs will cover the corresponding performance hit. Lather, rinse, repeat for the next launch. New tricks, new reckless performance gains, big uplift numbers, hope it takes a little while before anybody points out the holes in the emperor's clothes. But at the end of the day, the actual performance progress over time is, I suspect, dramatically slower than what the naïve summation of individual launch-day claims would suggest. To your second point: I think it's here to stay as long as we allow someone else's code (via js, webassembly, and their ilk) to run on our processors as a matter of course. A rethink of the entire modern web, back to a simpler markup language that isn't Turing-complete and can't leak data back to the attacker's server, would be needed before we could turn the mitigations off and enjoy the performance we were promised. But of course, if we get rid of the modern web as we know it, we probably don't need all that performance anyway. An old BlueWave/QWK mailer consumes 10,000x less resources than a Gmail tab, you know?