The cr.yp.to microblog: 2022.06.15 09:57:32

2022.06.15 09:57:32 (1536981216636772353) from Daniel J. Bernstein, replying to "Christian Wissel (@Gnarfoz)" (1536977259998879745):

The claim I'm disputing isn't that turning off Turbo Boost makes something run slower. The claim I'm disputing is that turning off Turbo Boost "has an extreme system-wide performance impact".

Context

2022.06.15 08:24:55 (1536957907622928384) from "Ruben Kelevra (@RubenKelevra)":

Well, that depends on the workload. If you want maximum CPU cycles out of a CPU over its life span, you may be right. But starting a browser or loading a webpage needs only one or two cores, which obviously complete the task much faster at 3.8 GHz than say 2.4 GHz.

2022.06.15 08:44:22 (1536962803222708224) from Daniel J. Bernstein, replying to "Ruben Kelevra (@RubenKelevra)" (1536957907622928384):

"Obviously"? Have you measured the difference? Would you call it "extreme"? If it turns out that you're waiting primarily for the CPU to finish web-page computations (and not the network), wouldn't the best way to reduce latency be to split those computations across _all_ cores?

2022.06.15 09:38:36 (1536976451731431424) from "Christian Wissel (@Gnarfoz)":

That mixes two audiences unfairly: users, who might decide to go along with your suggestion that variable clock speed is hell and turn it off, and developers, who might be able to re-implement a program to use multi-threading. (developers might be users, but rarely vice-versa)

2022.06.15 09:41:49 (1536977259998879745) from "Christian Wissel (@Gnarfoz)", replying to "Christian Wissel (@Gnarfoz)" (1536976451731431424):

Recommending users turn off turbo boost, and when they inevitably say "but now my $something runs slower!" to reply "well then make it multi-threaded" is hardly a realistic solution. ;-) (Not saying it shouldn't be done, but not by them, most likely.)