The OP missed out the key word "series" from the actual blog. In this context 2.3k refers to 2300. Hopefully @dang can revise the title slightly or maybe just point to the actual patch - https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/#u
No, the limit is 80 characters, and the current title is 73, so "Series " would fit. Also, "2.3k", besides being confusing, is not actually an abbreviation of 2297. len('2297 Patch Series Would Improve Linux Build Times 50~80% & Fix "Dependency Hell"') == 80. Better would be to replace "Patch" with "Commit", since that's how Molnar describes it, but that would take rewording (or removal of quotes) to fit on HN. "Times" -> "Rates" would be sensible too.
who knows if the title of this post has been edited or not since then, there are no indicators whether it was or not edited even if it was in the past...
In relation to the article, it seems like Ingo Molnar did everyone a favor by doing some low level code clean up. I hope this gets tested and accepted.
Oh I agree, it was just wanting a correction to the title. The scope of a change that is 2.3kb vs 2.3k patches is quite large - my initial thought from the title was "oh, is there some super dumb flag no one noticed that we should check for in our own excessively slow projects?", but the actual change is less generically helpful.
What a misleading title from phoronix. It doesn’t reduce build times by 50-80%, but rather increases build rate by 50-80%. There is a big difference between the two.
Build time, I would assume would be a number like "it takes 4 minutes to build a kernel package"..
Build rate also assuming, is more like "We can build 50 of these in an hour on two servers"...
The two are related, but you can scale the rate with more hardware, whereas the time is limited to how fast your hardware is or how optimised the job is, no? So Improving the _time_ increases your rate without you needing to spend more on infra..
How does one scale the rate and not the time with a code change and not an infra one, assuming my thinking here is correct?
I think the point isn't subtleties about scaling with more hardware, but about the fact that the percentages mean very different things depending on whether they're describing times or rates.
A 50% improvement in build time means becoming 2x as fast. A 50% improvement in build rate means becoming 1.5x as fast.
An 80% improvement in build time means becoming 5x as fast. An 80% improvement in build rate means becoming 1.8x as fast.
Whenever I feel like I might be lost in some mathematic question I look at the extremes. Doesn't always help but often enough. Here it's "one of them could very well be more than 100% with an even better speedup, the other certainly not"
Imagine you can build 100 kernels per hour. If you increase build rate by 50%, you can now build 150 kernels per hour. If you decrease build time by 50%, you can now build 100 kernels per 30 minutes, or 200 kernels per hour, which is more impressive. This is the sort of thing you become pedantic about when you play a lot of videogames that do %-based things to your character's stats.
"Please submit the original source. If a post reports on something found on another site, submit the latter."
https://news.ycombinator.com/newsguidelines.html