3 ms·
I think the most important takeaway from this article is that the defaults are crazy inefficient; they seem like pessimisation. I've seen this a lot with "moder
by userbinator 3y ago
I think the most important takeaway from this article is that the defaults are crazy inefficient; they seem like pessimisation. I've seen this a lot with "modern" toolchains and languages --- there's zero thought spent on efficiency, and an attitude of not caring at all about how much time or space something should take.
We went from 3.6 MiB to 400 bytes.
In an ideal world, you'd get those 400 bytes from the compiler when you set it to optimise for minimum size and give it the same "simplest possible Rust program", and without optimisation the output might be a little bit larger, but not 4 orders of magnitude larger.
Frankly, 3.6MB is nothing but insane for a program that does little more than exit. That's more than 2 floppies! We can add "Rust program that does nothing" to "List of Things That Turbo Pascal is Smaller Than" (https://news.ycombinator.com/item?id=22843140 https://news.ycombinator.com/item?id=22843140)
I wonder what it is that leads to such inefficiency. It would seem reasonable that a program that does very little, should also not contain much code. Therefore a compiler shouldn't generated much code. Yet somewhere along the way, drenched in multiple layers of abstraction, we've lost common sense?
A program that returns 42 is a 5-byte file in DOS: b8 2a 4c cd 21. (And if they'd been a little more thoughtful on the initial API, it could've been 3 bytes.)
- rcxdude 3y agoIf your ideal world is one without debug symbols, backtracing, and crash handling, then sure. It's not inefficiency to provide those features by default. If you want to turn them off, you can.
- ben0x539 3y ago> I wonder what it is that leads to such inefficiency. My understanding is that there is little corporate funding available to resource compiler engineers to prioritize "do nothing and exit" workloads.
- userbinator 3y agoIMHO it's nothing to do with "funding" (look at what comes out of the demoscene, for example); or perhaps you're espousing the same mentality that causes this. There isn't a need to "prioritize" anything, because these are really problems caused by doing unnecessary work in the first place: generating code for which the results of its execution will never be needed.
- ben0x539 3y agoThat's a weird rhethorical flourish. If there isn't a need to prioritize work to fix the thing we're complaining about, I guess we can stop complaining about it.
- userbinator 3y agoThat's what I'm saying: There would've been nothing to fix if they hadn't not cared at all about efficiency from the beginning, because such inefficiency would've never been created.
- flohofwoe 3y agoIn general I agree, but there may be cases where some bloat is justified (like getting readable callstacks on a crash, which may require at least some amount of debug information). Having said that, 3.5 Mbytes for a "do-nothing" exe is quite crazy though and should have been addressed long ago. I would expect somewhere between 4 and (to be generous) 64 KBytes.