4 ms·

The article does mention this a bit, but I would suggest to people to be a bit more careful about accusing everything of executable-size-bloat. We have the ment

by jerf 6y ago

The article does mention this a bit, but I would suggest to people to be a bit more careful about accusing everything of executable-size-bloat. We have the mentioned Unicode tables. Can you cut them? Sure, but now you've got a binary that only works in English and very-English like languages for no reason. We use 64-bit stuff for good reason, because we routinely blow out 32-bit limits, but that's 8 bytes for all sorts of things that used to be 4, pervasively throughout the code. We have localization support. We have some sort of async runtime or memory managing runtime or other thing like that. We have all sorts of things like this. If you sit down and take an inventory of what's going on, the minimum size for some sort of "serious" executable is still going to be quite a lot. (Could you move some of this stuff out of the executable? Yeah, but that really only addresses the immediately visible executable size and comes with tradeoffs of its own... it doesn't mean the executable is "smaller", it just means it's split into pieces.) It's a bit of a pipe dream now to expect some sort of "serious" executable (one that actually has all these concerns) to fit into half-a-megabyte anymore, just because Commodore 64 programs used to fit into a hundred kilobytes.

flohofwoe 6y ago
100 KBytes is quite bloaty for a C64 program and wouldn't even fit into RAM in one piece ;) But anyway... wouldn't the better and "obvious" solution be to move foundational things like the above mentioned UNICODE tables into operating systems (if they're not already provided) instead of shipping them with every application? After all, what's the point of operating systems if they don't provide commonly needed services (and I wonder if such solutions had even been considered for said Rust libraries). PS: One situation where binary size matters a lot is WASM running in browsers. It's not just download bandwidth, but also the time it takes to compile the executable. We're now back at WASM binaries stuttering on startup for a few seconds because the JIT needs to "warm up". For a very short time, when WASM was AOT compiled, this wasn't an issue. But it became an issue as people became careless about binary size and just-in-time compilation had to be reintroduced to cope with massively big WASM binaries.
- jandrese 6y ago
  Does this mean you need to ship a new Rust binary for every application you build when the Unicode consortium updates the tables?
  - PopsiclePete 6y ago
    If your application needs support for new emojis or some dead language, then yes.
- throwaway894345 6y ago
  > After all, what's the point of operating systems if they don't provide commonly needed services My answer is "managing access to shared resources"--the primary role of an OS is to allow multiple programs to run on the same hardware without needing to be aware of each other. I specifically don't think the OS should be a kitchen sink for common utilities / services. I would actually prefer fewer things managed by the OS (microkernel if not unikernel). In my utopia, the line between "OS" and "Hypervisor" would be very thin/blurry. If we really want to be space-conscious, I think the answer is dynamic linkage, although I think people have forgotten the horror that is dependency hell. Nix conceptually provides an answer for dependency hell, but in my experience there remains quite a chasm between what Nix promises or aspires towards and what it actually delivers. For the time being, I have to think that static binaries are overwhelmingly the most economical solution when you account for time spent mucking with dependencies.
- gpm 6y ago
  > what's the point of operating systems if they don't provide commonly needed services To abstract over hardware, including to allow running multiple programs simultaneously on the same hardware. I'd argue that there's pretty widespread agreement in how we actually deploy modern systems when given the choice, that this is all we want the operating system to do too. There's all these operating systems that try to do more (e.g. approximately every linux distribution ever), and yet modern software primarily runs in some sort of sandbox who doesn't allow any of that to seep into the environment. On servers that sandbox looks like "containers" or less frequently "jails". On clients that sandbox looks like "a browser" or "electron". Empirically the idea of shipping commonly used dependencies with the hardware abstraction layer, seems to have been the wrong idea. Even if you disagree with that, certainly it's not the case that it's the only point of shipping the hardware abstraction layer (operating system) in the first place.
agumonkey 6y ago
Reminds me of the articles about text processing in haskell vs C. haskell wasn't as lean but it was more general (full unicode support). There was no mystery in the size difference.

by jerf 6y ago

flohofwoe 6y ago

100 KBytes is quite bloaty for a C64 program and wouldn't even fit into RAM in one piece ;) But anyway... wouldn't the better and "obvious" solution be to move foundational things like the above mentioned UNICODE tables into operating systems (if they're not already provided) instead of shipping them with every application? After all, what's the point of operating systems if they don't provide commonly needed services (and I wonder if such solutions had even been considered for said Rust libraries). PS: One situation where binary size matters a lot is WASM running in browsers. It's not just download bandwidth, but also the time it takes to compile the executable. We're now back at WASM binaries stuttering on startup for a few seconds because the JIT needs to "warm up". For a very short time, when WASM was AOT compiled, this wasn't an issue. But it became an issue as people became careless about binary size and just-in-time compilation had to be reintroduced to cope with massively big WASM binaries.

jandrese 6y ago
Does this mean you need to ship a new Rust binary for every application you build when the Unicode consortium updates the tables?
- PopsiclePete 6y ago
  If your application needs support for new emojis or some dead language, then yes.
throwaway894345 6y ago
> After all, what's the point of operating systems if they don't provide commonly needed services My answer is "managing access to shared resources"--the primary role of an OS is to allow multiple programs to run on the same hardware without needing to be aware of each other. I specifically don't think the OS should be a kitchen sink for common utilities / services. I would actually prefer fewer things managed by the OS (microkernel if not unikernel). In my utopia, the line between "OS" and "Hypervisor" would be very thin/blurry. If we really want to be space-conscious, I think the answer is dynamic linkage, although I think people have forgotten the horror that is dependency hell. Nix conceptually provides an answer for dependency hell, but in my experience there remains quite a chasm between what Nix promises or aspires towards and what it actually delivers. For the time being, I have to think that static binaries are overwhelmingly the most economical solution when you account for time spent mucking with dependencies.
gpm 6y ago
> what's the point of operating systems if they don't provide commonly needed services To abstract over hardware, including to allow running multiple programs simultaneously on the same hardware. I'd argue that there's pretty widespread agreement in how we actually deploy modern systems when given the choice, that this is all we want the operating system to do too. There's all these operating systems that try to do more (e.g. approximately every linux distribution ever), and yet modern software primarily runs in some sort of sandbox who doesn't allow any of that to seep into the environment. On servers that sandbox looks like "containers" or less frequently "jails". On clients that sandbox looks like "a browser" or "electron". Empirically the idea of shipping commonly used dependencies with the hardware abstraction layer, seems to have been the wrong idea. Even if you disagree with that, certainly it's not the case that it's the only point of shipping the hardware abstraction layer (operating system) in the first place.

agumonkey 6y ago

Reminds me of the articles about text processing in haskell vs C. haskell wasn't as lean but it was more general (full unicode support). There was no mystery in the size difference.