[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)