5 ms·

The other day I was wondering what would happen if all operating systems would stop developing and only optimise for a week or 2. How much time and electricity

The other day I was wondering what would happen if all operating systems would stop developing and only optimise for a week or 2. How much time and electricity could have been saved? If you add up an optimisation of just a nanosecond in like openSSH, how much would that do globally?

nikhizzle 5y ago
I used to be a kernel developer at Apple starting in 2006. Internally, every alternate major release was exactly this. All common paths were identified, and most of the dev time on the release was spent on optimizing those features to hit a goal for the path. Eg. moving 100 files in finder should not take more than x ms
- w-m 5y ago
  The upgrade from Leopard to Snow Leopard on a plastic MacBook just made everything better. Things were faster, smoother, and you could run more things at the same time without killing the machine. It was the perfect OS. Then when Lion came around, it was the exact opposite, it felt terribly buggy, and made everything clunky and worse. At least that's my memory of these OS updates. Makes me wonder whether this alternate major release cycle was a good idea. If you delay all feature development for a year, you'll get a barrage of features once the performance-only OS version is out the door, and there's not enough time to do all of them properly, so you get buggy and slow versions. Maybe doing performance improvements and feature development at the same time would have been the better choice? How is it being done at Apple nowadays?
  - nikhizzle 5y ago
    I do not know, Apple is a place where most practices are need to know only.
georgyo 5y ago
> If you add up an optimization of just a nanosecond in like openSSH, how much would that do globally? I believed optimizations like that at a global scale will not have any impact. Lets say that this nanosecond will be saved trillions of time a day. Resulting in minutes to an hour a day saved globally. * Not a single user will notice. * In 99.99% of cases the CPU will not be fully pegged and thus that one nanosecond of compute will not be used to do something else at all. * CPU throttling isn't that fast so, you won't even save that much power. If we bump it up by 6 orders of magnitude to a millisecond that all remains true. Even though you are potentially saving 100s of years of computing time a day. Extremely small gains distributed across very large number of machines don't tend to be as impactful as you would hope on a global scale. This is not to say that small gains are worthless. Many small gains added together can be substantial.
- DudeInBasement 5y ago
  It's not the through put, but the fact when the CPU is idle it is sleeping saving power. This is true on mobile, not for servers as internally they'll poll their ethernet phys.
- gameswithgo 5y ago
  If you make a bicycle one second faster over 40 kilometers, the user does not notice. But the user does win the race by 1 second instead of losing it. That is, things can be of enormous utility even when the user doesn't notice.
im3w1l 5y ago
Very optimized projects are out-competed by well-factored but less optimized projects, because the latter ones can add features faster. Thats why we are where we are today.
- gameswithgo 5y ago
  A great deal of software has room to be made an order of magnitude faster with no negative impact on maintainability.
- somethingAlex 5y ago
  In the new technology sector this is certainly true. Find your product-market fit and then optimize when you become mature and scale up. But aren't we talking about extremely mature kernel code here? My impression is that all kernel distros in high use are optimized but they are general use software. The degree to which you may optimize software is constrained but the diversity of use cases you must support.

nikhizzle 5y ago

I used to be a kernel developer at Apple starting in 2006. Internally, every alternate major release was exactly this. All common paths were identified, and most of the dev time on the release was spent on optimizing those features to hit a goal for the path. Eg. moving 100 files in finder should not take more than x ms

w-m 5y ago
The upgrade from Leopard to Snow Leopard on a plastic MacBook just made everything better. Things were faster, smoother, and you could run more things at the same time without killing the machine. It was the perfect OS. Then when Lion came around, it was the exact opposite, it felt terribly buggy, and made everything clunky and worse. At least that's my memory of these OS updates. Makes me wonder whether this alternate major release cycle was a good idea. If you delay all feature development for a year, you'll get a barrage of features once the performance-only OS version is out the door, and there's not enough time to do all of them properly, so you get buggy and slow versions. Maybe doing performance improvements and feature development at the same time would have been the better choice? How is it being done at Apple nowadays?
- nikhizzle 5y ago
  I do not know, Apple is a place where most practices are need to know only.

georgyo 5y ago

> If you add up an optimization of just a nanosecond in like openSSH, how much would that do globally? I believed optimizations like that at a global scale will not have any impact. Lets say that this nanosecond will be saved trillions of time a day. Resulting in minutes to an hour a day saved globally. * Not a single user will notice. * In 99.99% of cases the CPU will not be fully pegged and thus that one nanosecond of compute will not be used to do something else at all. * CPU throttling isn't that fast so, you won't even save that much power. If we bump it up by 6 orders of magnitude to a millisecond that all remains true. Even though you are potentially saving 100s of years of computing time a day. Extremely small gains distributed across very large number of machines don't tend to be as impactful as you would hope on a global scale. This is not to say that small gains are worthless. Many small gains added together can be substantial.

DudeInBasement 5y ago
It's not the through put, but the fact when the CPU is idle it is sleeping saving power. This is true on mobile, not for servers as internally they'll poll their ethernet phys.
gameswithgo 5y ago
If you make a bicycle one second faster over 40 kilometers, the user does not notice. But the user does win the race by 1 second instead of losing it. That is, things can be of enormous utility even when the user doesn't notice.

im3w1l 5y ago

Very optimized projects are out-competed by well-factored but less optimized projects, because the latter ones can add features faster. Thats why we are where we are today.

gameswithgo 5y ago
A great deal of software has room to be made an order of magnitude faster with no negative impact on maintainability.
somethingAlex 5y ago
In the new technology sector this is certainly true. Find your product-market fit and then optimize when you become mature and scale up. But aren't we talking about extremely mature kernel code here? My impression is that all kernel distros in high use are optimized but they are general use software. The degree to which you may optimize software is constrained but the diversity of use cases you must support.