1. 1

    This is interesting! Anyone know if Go has any way to do something similar?

    1. 0


      Through build tags. The standard library uses that a lot for system calls; I’m sure there’s optimizations for architectures somewhere in there as well

      1. 5

        Not really. All architecture optimizations in Go (except the ones controlled by GOARM) are activated at runtime. The idea is that binaries should run everywhere. Also, the compiler does not do auto-vectorization like LLVM.

        1. 2

          To expand on this, go binaries can contain instructions that the current architecture does not support (like say AES acceleration). Support for those instructions is detected at runtime using CPUID. https://golang.org/src/crypto/internal/cipherhw/asm_amd64.s

          Works out reasonably well for core stdlib stuff that has been optimized like crazy like byte searching. Unfortunately it doesn’t really solve the problem of making arbitrary go source code leverage cpu features.

    1. 4

      For example, exa prints human-readable file sizes by default (when would you not want that?)

      Um, fairly frequently, actually – knowing the exact-to-the-byte size of a file (or a few files) can be quite useful.

      1. 13

        I think their point is that the default output for a tool such as ls or exa should be human-readable.

        Humans are uaully the ones who don’t like extra typing. I don’t often hear computers complain about that :p

        If you’re automating something, you can probably read the manpage and figure out that there’s a -B flag to get file sizes in bytes if that’s something you need, but I think most people would find 946831165B much more difficult to conceptualize than 946MB.

        1. 3

          Sure – my point was that non-“human-readable” file sizes are not completely useless, as the parenthetical in TFA seems to be trying to imply.