4 ms·

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

392 points by marcodiego 5y ago

rolph 5y ago
this doesnt mean a single 2.3 kilobyte patch. this means an enormous suite of more than 2000 individual patches
- devNoise 5y ago
  Yes, the "Massive ~2.3k Patch Series" in the article title give a better idea about this patch vs "2.3K Patch" HN title.
  - devNoise 5y ago
    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.
    - AlotOfReading 5y ago
      Yeah, it's hard to imagine spending 2 straight years untangling the Gordian Knot even this far. What an amazing feat by Ingo.
- tfsh 5y ago
  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 https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/#u
  - hffft 5y ago
    > 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.
    - mkl 5y ago
      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.
      - hffft 5y ago
        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...
olliej 5y ago
Title should be fixed. This isn’t a 2.3k patch. It’s a series of 2300 patches.
- colechristensen 5y ago
  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.
  - db48x 5y ago
    It already is 2,300 small, self–contained, easily digestible requests.
    - asddubs 5y ago
      i think that was their point
  - olliej 5y ago
    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.
    - asddubs 5y ago
      improve your build times today by up to 80%, following these simple 2300 steps
ummonk 5y ago
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.
- cyberpunk 5y ago
  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?
  - gjm11 5y ago
    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.
    - usrusr 5y ago
      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"
    - cyberpunk 5y ago
      Ahh, I got it now. Doh. Thank you!
  - deleted 5y ago
    [deleted]
dang 5y ago
We merged (most of) the comments into https://news.ycombinator.com/item?id=29777048 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 https://news.ycombinator.com/newsguidelines.html

392 points by marcodiego 5y ago

rolph 5y ago

this doesnt mean a single 2.3 kilobyte patch. this means an enormous suite of more than 2000 individual patches

devNoise 5y ago
Yes, the "Massive ~2.3k Patch Series" in the article title give a better idea about this patch vs "2.3K Patch" HN title.
- devNoise 5y ago
  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.
  - AlotOfReading 5y ago
    Yeah, it's hard to imagine spending 2 straight years untangling the Gordian Knot even this far. What an amazing feat by Ingo.
tfsh 5y ago
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 https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/#u
- hffft 5y ago
  > 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.
  - mkl 5y ago
    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.
    - hffft 5y ago
      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...

olliej 5y ago

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

colechristensen 5y ago
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.
- db48x 5y ago
  It already is 2,300 small, self–contained, easily digestible requests.
  - asddubs 5y ago
    i think that was their point
- olliej 5y ago
  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.
  - asddubs 5y ago
    improve your build times today by up to 80%, following these simple 2300 steps

ummonk 5y ago

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.

cyberpunk 5y ago
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?
- gjm11 5y ago
  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.
  - usrusr 5y ago
    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"
  - cyberpunk 5y ago
    Ahh, I got it now. Doh. Thank you!
- deleted 5y ago
  [deleted]

dang 5y ago

We merged (most of) the comments into https://news.ycombinator.com/item?id=29777048 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 https://news.ycombinator.com/newsguidelines.html