2022.06.15 10:05:22 (1536983188353888258) from Daniel J. Bernstein, replying to "Ruben Kelevra (@RubenKelevra)" (1536977476714381315):
If the user is waiting then the time is long enough that the unoptimized code with (say) 2x Turbo Boost should be replaced by optimized code with (say) 4x vectorization, 4x multithreading, even though this limits Turbo Boost. The most important bottlenecks have done this already.
2022.06.15 09:21:26 (1536972131799486464) from Daniel J. Bernstein, replying to "Ruben Kelevra (@RubenKelevra)" (1536970083435790336):
Your numbers seem to indicate that, on your 4-core machine, Firefox startup wasn't even managing to keep 2 cores active on average. Could this limited attention to Firefox startup optimization perhaps be a hint that most users aren't spending all day waiting for Firefox to start?
2022.06.15 09:27:50 (1536973742215028736) from Daniel J. Bernstein:
The code that users spend the most time waiting for has much bigger incentives to be vectorized and multithreaded, even though this limits the Turbo Boost speedup. I'd expect a claim of an "extreme system-wide performance impact" to be backed by numbers for common bottlenecks.
2022.06.15 09:42:18 (1536977381998661633) from "Ruben Kelevra (@RubenKelevra)":
Surely, that was just the first thing I could think of which is slow when I'm on battery. The point of turbo on the other hand is, that most code is not optimized to be heavily multithreaded and most users don't spend the whole day running it. It's bursts like this which...
2022.06.15 09:42:40 (1536977476714381315) from "Ruben Kelevra (@RubenKelevra)", replying to "Ruben Kelevra (@RubenKelevra)" (1536977381998661633):
... is the needed performance and results in the perceived speed.