4 ms·

// What happens is that S1 is different for different computer configurations, and processing needs to happen. The computer and OS config doesn't change often.

by petra 7y ago

// What happens is that S1 is different for different computer configurations, and processing needs to happen. The computer and OS config doesn't change often. And it's doesn't seem slow to test that. So caching at boot should work. And caching is a low effort optimization. So it should have been implemented early. But we don't have caching at boot, why?

salawat 7y ago
The two hard things in computer science are naming things, and cache invalidation. Remember; the computer could quite literally have been completely reconfigured out from under the BIOS. Testing that everything is the same from the computer's point of view is anything but straightforward. Also, most recognizable boot time isn't spent waiting on BIOS and POST; it's spent waiting for either the boot loader, disk encryption, or the OS to spin up all the background stuff (graphics stacks, session managers, HAL's, message busses, desktop environments, network services... etc) it needs to offer for fulfilling the particular purpose the system is intended for. Computation is amazingly fast, but by no means either free or magic. Everything takes time. However, I make no excuses for Windows: They had 3-5 second boot nailed for a while. Then, they done bloated it to the point of unrecognizability.
- egypturnash 7y ago
  Usually the configuration stays the same, though - why not a way for the user to indicate when it has? Hold down an awkward combination of three far-flung keys while booting, the BIOS wakes up and checks every device plugged into it, otherwise it just pulls it in from a cache. (And how much does the average computer's config change? How many users never change a single part of the hardware configuration of their computer for its entire lifetime? A hobbyist who built their own might swap out CPU/GPU/drive/ram/etc, but how many people upgrade their laptops in any way?) Get all that backup stuff spun up. Save the state of the entire computer the same way you're saving a hibernation snapshot. Next boot, just pull that snapshot up. Something makes that snapshot crash? Reset and run the slow boot, either because the system caught this, or because the user held down the "invalidate bootup snapshot" chord. Although realistically I never reboot my computer any more unless I'm doing an OS upgrade anyway. It's all just "sleep" and "wake up" nowadays for me, so I don't care if bootup adds a minute or two to the end of the half an hour or so my computer spent downloading the update and applying it. Maybe a cold boot just isn't worth optimizing any more.
  - cududa 7y ago
    As someone who worked on boot up sequence in Windows, that won’t work. You could kill components in the system if someone forgets to press the right keys on bootup. The snapshot method you mention is essentially how it already works
- deleted 7y ago
  [deleted]
- fallingfrog 7y ago
  ..why could you not just use some kind of hash of all the relevant files/drivers to tell if the system config has changed? As in: the os has a flag that says if each file is used in startup. If a startup file is written then the startup config hash is recalculated. It’s a global hash that uses every startup file. If the startup hash does not match the startup hash from the last bootup, then we don’t use the cached config. Seems straightforward enough to me.
  - salawat 7y ago
    Because all of that is on the hard disk; which may be encrypted. There's more going on during boot than you think. Bootloaders are meant to be small and simple; just enough to hand off to the OS. If your OS takes a minute to get its stuff straight; there isn't really much you can do to make the boot faster.
    - fallingfrog 7y ago
      Oh ok, so in other words a lot of the time is before the os even reads the hard drive? That would sort of make the caching approach less advantageous
      - salawat 7y ago
        Other way around. BIOS and POST tend to be complete in <2-3 seconds, even on the slowest boxes I've worked with. It's exceedingly fast. The UEFI implementations on modern computers then have to scan the hard drive GPT to find the bootloaders, if there are any. UEFI Then hands off to the bootloader that then begin initializing the OS. At this point, you're probably anywhere from 5-7 seconds in in my experience. As your OS begins loading, it has to spin up the filesystem, and locate all the necessary files required to do it's thing. Most critical hardware (mouse, keyboard, video drivers) are loaded and initialized at this point. Generally, your OS would be in some equivalent of a single-user mode at this point. After the necessary local filesystem shenanigans are complete, non-critical device drivers (network, sound card, exotic storage media) tend to get initialized. Network drives if properly configured might be mapped, but generally (I.e. Windows) loads Most remote volumes after login, which is generally after the system enters multi-user mode. Windows in particular is incredibly annoying because vast tracts of configuration data is tracked in the registry; an in-memory hierarchical key/value pair binary database. Most "Windows updates" tend to involve shell scripts/installers running and performing filesystem and registry updates while you're sitting there really wishing you knew why stuff was taking so long. Stuff is taking so long because the registry is a bloody mess, and your filesystem is getting polluted by Windows not cleaning up after itself. God help you if you killed an update in the middle; as the scripts probably were not crafted with a User's convenience in mind, and therefore are likely to fail in exceedingly interesting ways. Though I habitually try to be the most horribly behaved user in that regard, and I've only encountered a handful of updates that when interrupted had caused Bad Things(tm) to happen. If you aren't into breaking things for fun and profit though, I'd not advise you doing the same. Long story short; 5-7 seconds is the absolute longest I'll tolerate for boot from hardware to OS selection. After that, faster boots depend on OS developers to get things going faster.
- bradknowles 7y ago
  The two hard problems are: Cache invalidation Naming And off-by-one problems. FTFY. ;)
bradknowles 7y ago
But macOS does exactly that. The second boot is much faster than the first one after an OS configuration change, because it has to figure out what the new cache order has to be. This feature was introduced years ago. What is stopping other OSes from doing the same?

by petra 7y ago

salawat 7y ago

The two hard things in computer science are naming things, and cache invalidation. Remember; the computer could quite literally have been completely reconfigured out from under the BIOS. Testing that everything is the same from the computer's point of view is anything but straightforward. Also, most recognizable boot time isn't spent waiting on BIOS and POST; it's spent waiting for either the boot loader, disk encryption, or the OS to spin up all the background stuff (graphics stacks, session managers, HAL's, message busses, desktop environments, network services... etc) it needs to offer for fulfilling the particular purpose the system is intended for. Computation is amazingly fast, but by no means either free or magic. Everything takes time. However, I make no excuses for Windows: They had 3-5 second boot nailed for a while. Then, they done bloated it to the point of unrecognizability.

egypturnash 7y ago
Usually the configuration stays the same, though - why not a way for the user to indicate when it has? Hold down an awkward combination of three far-flung keys while booting, the BIOS wakes up and checks every device plugged into it, otherwise it just pulls it in from a cache. (And how much does the average computer's config change? How many users never change a single part of the hardware configuration of their computer for its entire lifetime? A hobbyist who built their own might swap out CPU/GPU/drive/ram/etc, but how many people upgrade their laptops in any way?) Get all that backup stuff spun up. Save the state of the entire computer the same way you're saving a hibernation snapshot. Next boot, just pull that snapshot up. Something makes that snapshot crash? Reset and run the slow boot, either because the system caught this, or because the user held down the "invalidate bootup snapshot" chord. Although realistically I never reboot my computer any more unless I'm doing an OS upgrade anyway. It's all just "sleep" and "wake up" nowadays for me, so I don't care if bootup adds a minute or two to the end of the half an hour or so my computer spent downloading the update and applying it. Maybe a cold boot just isn't worth optimizing any more.
- cududa 7y ago
  As someone who worked on boot up sequence in Windows, that won’t work. You could kill components in the system if someone forgets to press the right keys on bootup. The snapshot method you mention is essentially how it already works
deleted 7y ago
[deleted]
fallingfrog 7y ago
..why could you not just use some kind of hash of all the relevant files/drivers to tell if the system config has changed? As in: the os has a flag that says if each file is used in startup. If a startup file is written then the startup config hash is recalculated. It’s a global hash that uses every startup file. If the startup hash does not match the startup hash from the last bootup, then we don’t use the cached config. Seems straightforward enough to me.
- salawat 7y ago
  Because all of that is on the hard disk; which may be encrypted. There's more going on during boot than you think. Bootloaders are meant to be small and simple; just enough to hand off to the OS. If your OS takes a minute to get its stuff straight; there isn't really much you can do to make the boot faster.
  - fallingfrog 7y ago
    Oh ok, so in other words a lot of the time is before the os even reads the hard drive? That would sort of make the caching approach less advantageous
    - salawat 7y ago
      Other way around. BIOS and POST tend to be complete in <2-3 seconds, even on the slowest boxes I've worked with. It's exceedingly fast. The UEFI implementations on modern computers then have to scan the hard drive GPT to find the bootloaders, if there are any. UEFI Then hands off to the bootloader that then begin initializing the OS. At this point, you're probably anywhere from 5-7 seconds in in my experience. As your OS begins loading, it has to spin up the filesystem, and locate all the necessary files required to do it's thing. Most critical hardware (mouse, keyboard, video drivers) are loaded and initialized at this point. Generally, your OS would be in some equivalent of a single-user mode at this point. After the necessary local filesystem shenanigans are complete, non-critical device drivers (network, sound card, exotic storage media) tend to get initialized. Network drives if properly configured might be mapped, but generally (I.e. Windows) loads Most remote volumes after login, which is generally after the system enters multi-user mode. Windows in particular is incredibly annoying because vast tracts of configuration data is tracked in the registry; an in-memory hierarchical key/value pair binary database. Most "Windows updates" tend to involve shell scripts/installers running and performing filesystem and registry updates while you're sitting there really wishing you knew why stuff was taking so long. Stuff is taking so long because the registry is a bloody mess, and your filesystem is getting polluted by Windows not cleaning up after itself. God help you if you killed an update in the middle; as the scripts probably were not crafted with a User's convenience in mind, and therefore are likely to fail in exceedingly interesting ways. Though I habitually try to be the most horribly behaved user in that regard, and I've only encountered a handful of updates that when interrupted had caused Bad Things(tm) to happen. If you aren't into breaking things for fun and profit though, I'd not advise you doing the same. Long story short; 5-7 seconds is the absolute longest I'll tolerate for boot from hardware to OS selection. After that, faster boots depend on OS developers to get things going faster.
bradknowles 7y ago
The two hard problems are: Cache invalidation Naming And off-by-one problems. FTFY. ;)

bradknowles 7y ago

But macOS does exactly that. The second boot is much faster than the first one after an OS configuration change, because it has to figure out what the new cache order has to be. This feature was introduced years ago. What is stopping other OSes from doing the same?