5 ms·

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 mo

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]
ben0x539 5y ago
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.
barkingcat 5y ago
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.

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]

ben0x539 5y ago

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.

barkingcat 5y ago

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.