3 ms·

I wrote a Gigatron emulator in Zig for Win32. Compiled with ReleaseFast (not even ReleaseSmall!) it is only 446KB. The full-fat debug version is only just over

I wrote a Gigatron emulator in Zig for Win32. Compiled with ReleaseFast (not even ReleaseSmall!) it is only 446KB. The full-fat debug version is only just over a MB. 2MB is a lot for a binary.

spicybright 5y ago
Is it really though? 2mb is practically nothing on modern machines. And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy. It's like, yes, if you turn off the A/C in your muscle car, you'll technically get a few extra horse power. But past some philosophical ideal of squeezing out every bit of horse power you can, it has a negligible effect on the operation of the car. Now if you're working on a weed wacker engine or something, yeah that would matter. But you wouldn't pick a giant beefy engine and expect it to work as well as a tiny lightweight one.
- titzer 5y ago
  > 2mb is practically nothing on modern machines. There are plenty of embedded systems that have <= 1mb of memory. E.g. a popular one is Teensy (https://www.pjrc.com/store/teensy40.html https://www.pjrc.com/store/teensy40.html).
- AnIdiotOnTheNet 5y ago
  > Is it really though? 2mb is practically nothing on modern machines. In general, I agree actually. I think hemming and hawing over duplicated shared libraries in particular makes no sense for most modern systems. Still, 2MB is a pretty damn big overhead to put on every binary the way Go does. Not that it isn't a considered trade off or anything, I'm just saying. > And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy. That's my point: there's no optimization in the full-fat debug and it does contain everything it can and it's still a little more than half the size of a completely empty Go binary. 2MB is huge. For the ReleaseFast version all I did was tell the compiler to optimize for speed and otherwise put no effort into making anything size efficient.
  - spicybright 5y ago
    I'm still not really getting why "huge" matters though, unless you're doing very small embedded work. Which I'd argue Go isn't a great choice in the same way that running full linux on a limited microcontroller is not a good choice. Every systems language shouldn't have to over complicate it's run time to squeeze kilobytes out if 99% of use cases are running on modern personal computers. (C or TinyGo, or a variety of languages are better suited for embedded) Like, yeah, 5 cents is huge compared to 1 cent, but we're dealing in hundred dollar bills here.

I wrote a Gigatron emulator in Zig for Win32. Compiled with ReleaseFast (not even ReleaseSmall!) it is only 446KB. The full-fat debug version is only just over a MB. 2MB is a lot for a binary.

spicybright 5y ago

Is it really though? 2mb is practically nothing on modern machines. And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy. It's like, yes, if you turn off the A/C in your muscle car, you'll technically get a few extra horse power. But past some philosophical ideal of squeezing out every bit of horse power you can, it has a negligible effect on the operation of the car. Now if you're working on a weed wacker engine or something, yeah that would matter. But you wouldn't pick a giant beefy engine and expect it to work as well as a tiny lightweight one.

titzer 5y ago
> 2mb is practically nothing on modern machines. There are plenty of embedded systems that have <= 1mb of memory. E.g. a popular one is Teensy (https://www.pjrc.com/store/teensy40.html https://www.pjrc.com/store/teensy40.html).
AnIdiotOnTheNet 5y ago
> Is it really though? 2mb is practically nothing on modern machines. In general, I agree actually. I think hemming and hawing over duplicated shared libraries in particular makes no sense for most modern systems. Still, 2MB is a pretty damn big overhead to put on every binary the way Go does. Not that it isn't a considered trade off or anything, I'm just saying. > And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy. That's my point: there's no optimization in the full-fat debug and it does contain everything it can and it's still a little more than half the size of a completely empty Go binary. 2MB is huge. For the ReleaseFast version all I did was tell the compiler to optimize for speed and otherwise put no effort into making anything size efficient.
- spicybright 5y ago
  I'm still not really getting why "huge" matters though, unless you're doing very small embedded work. Which I'd argue Go isn't a great choice in the same way that running full linux on a limited microcontroller is not a good choice. Every systems language shouldn't have to over complicate it's run time to squeeze kilobytes out if 99% of use cases are running on modern personal computers. (C or TinyGo, or a variety of languages are better suited for embedded) Like, yeah, 5 cents is huge compared to 1 cent, but we're dealing in hundred dollar bills here.