2.3k Patch Would Improve Linux Build Times 50~80% & Fix “Dependency Hell” | Hacker News Reader

2.3k Patch Would Improve Linux Build Times 50~80% & Fix “Dependency Hell”

phoronix.com

392 pointsmarcodiego22 comments

We merged (most of) the comments into https://news.ycombinator.com/item?id=29777048, which was posted later but has the original source.

"Please submit the original source. If a post reports on something found on another site, submit the latter."

https://news.ycombinator.com/newsguidelines.html

this doesnt mean a single 2.3 kilobyte patch.

this means an enormous suite of more than 2000 individual patches

Yes, the "Massive ~2.3k Patch Series" in the article title give a better idea about this patch vs "2.3K Patch" HN title.

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.

Yeah, it's hard to imagine spending 2 straight years untangling the Gordian Knot even this far. What an amazing feat by Ingo.

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

> The OP missed out the key word "series" from the actual blog.

Probably didn't miss it... probably hit the very strict/short HN post title limit.

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...

Title should be fixed. This isn’t a 2.3k patch. It’s a series of 2300 patches.

That makes more sense. One would think the only response to such a big change would be to insist it be made into many smaller requests.

It already is 2,300 small, self–contained, easily digestible requests.

i think that was their point

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.

improve your build times today by up to 80%, following these simple 2300 steps

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.

What's the difference then?

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"

Ahh, I got it now. Doh. Thank you!

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.

It's the good old 50% off vs Buy 1 Get 1 half price trick.

intellectually dishonest (as in trying to describe increase x in built rate as improving by x%) but great for selling headlines.

Reply on news.ycombinator.com