[HN Gopher] Analysis of the overhead of a minimal Zig program ___________________________________________________________________ Analysis of the overhead of a minimal Zig program Author : matu3ba Score : 68 points Date : 2022-01-02 20:50 UTC (2 hours ago) (HTM) web link (zig.news) (TXT) w3m dump (zig.news) | dleslie wrote: | Interestingly, I can't seem to get an empty nim programme below | 32k. #> touch foo.nim #> nim c -d:release | --opt:size -d:strip -d:danger foo.nim #> ls -lhs foo | cut | -d\ -f1 32K | b3morales wrote: | Same with Swift (on Mac) % touch foo.swift | % swiftc -Osize -Xlinker -x foo.swift % ls -lh foo | | cut -d' ' -f10 33K % strip foo % ls -lh | foo | cut -d' ' -f10 33K | goodpoint wrote: | With --os:standalone and panicoverride.nim it goes down to 15k | | And down to *150 bytes* with some hacks | https://hookrace.net/blog/nim-binary-size/ | NikolaeVarius wrote: | > I've watched friends try Go and immediately uninstall the | compiler when they see that the resulting no-op demo program is | larger than 2 MiB. | | That seems a bit extreme | | > Overhead breeds complacency -- if your program is already | several megabytes in size, what's a few extra bytes wasted? Such | thinking leads to atrocities like writing desktop text editors | bundled on top of an entire web browser | | I'm still on board | unbanned wrote: | Don't tell them about node js (electron)!! | JulianMorrison wrote: | I'm imagining that the Go people would have a hard time making | the compiled program smaller, because they're bundling in a M:N | threading system, inter-thread channels, a garbage collector, a | stack resizer, a syscall parking and reactivation system, and | all of the above are by necessity mutually interdependent. | jaytaylor wrote: | Perhaps functional chunks could be excluded from the final | emitted binary when they're unused / unreachable from main? | | How hard would it be to check the AST for a go program's | usage of channels, goroutines, etc at compile time? As these | are features not used by the go language itself, it seems | nearly trivial (no jit or other super dynamicism). | spicybright wrote: | What irks me most about people that complain about large | binaries for empty programs is that every program past Hello | World will actually use all these features. | | So why waste the effort putting in a code path to disable | these things except for some philosophical ideal? | | Code in Asm or C if you need a hello world that can fit on a | floppy disk, you're not really doing anything substantial | anyways... | | There's plenty of acceptable middle ground between Go | binaries using 2mb minimum and full electron apps eating your | ram. | moonchild wrote: | No comment on content. However. | | > What's up with the and rsp,0xfffffffffffffff0? That's because | the function manually aligns the stack to the next 16-byte | boundary. I'm not sure why the stdlib does this. The SystemV ABI | (SS2.3.1) guarantees an initial alignment of 16 already, so it | should be superfluous. | | _Linux_ does not make any such guarantee, however; so in order | for _start to call functions using the sysv ABI in a compliant | fashion, it must provide them with an aligned stack. | asdfasgasdgasdg wrote: | It's an interesting analysis, but I'm a little skeptical that | there is any partical scenario where Linux would be runnable and | a 1.2 kB program will significantly underperform a 600B program. | The program would have to be small indeed for this difference to | be material. | Aransentin wrote: | Between a 1.2 KiB and 600 Byte program, probably not, no. I | wrote that section to confront the general idea that program | startup performance is irrelevant and that optimizing it | doesn't matter; a language that assumes so will start piling up | features until it actually does, like it does for C in the | example. | goodpoint wrote: | This is gold: | | """ Overhead breeds complacency -- if your program is already | several megabytes in size, what's a few extra bytes wasted? Such | thinking leads to atrocities like writing desktop text editors | bundled on top of an entire web browser, and I think it would be | nice to have a language that pushes people to be a bit more | mindful of the amount of resources they're using. """ | ftrobro wrote: | "Aggressively stripping out all the unnecessary trash that the | linker puts into it makes it 297 bytes" | | Reminds me of how impressive 256 byte intros are, like this one: | | https://www.youtube.com/watch?v=w72MXbAIJVg ___________________________________________________________________ (page generated 2022-01-02 23:00 UTC)