11–20 of 24 posts
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?
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 r…
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.
this doesnt mean a single 2.3 kilobyte patch. this means an enormous suite of more than 2000 individual patches
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
Probably didn't miss it... probably hit the very strict/short HN post title limit.
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 r…
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 r…
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 r…
intellectually dishonest (as in trying to describe increase x in built rate as improving by x%) but great for selling headlines.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 r…
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…