5 ms·

Impressive work getting Zig self-hosting. However: > As for less memory, I think this is simply a clear win for Zig. No other modern languages compete with the

Impressive work getting Zig self-hosting. However: > As for less memory, I think this is simply a clear win for Zig. No other modern languages compete with the tiny memory footprints of Zig software. Is not true at all. There are several other modern languages that compete with Zig for small memory footprints.

geodel 5y ago
Would you tell about those languages or they are left as an exercise to readers?
- elcritch 5y ago
  Sort of left it to the readers and hopefully encourage people to investigate for themselves. It's far too easy to get into "this benchmark vs this benchmark", etc. Memory usage is overall a complicated topic, which I think Andrew's comment doesn't do justice to. Granted the Zig team has done some impressive work, much of the memory usage & bloat in the C++ world comes from real world programs and libraries and the inevitable drift in program architecture over time. However, I could believe Zig's stdlib and culture encourages low memory footprints, but there isn't anything novel in the language that makes it inherently lower memory footprint. Though to name a few languages I'd say that can be directly comparable are Rust, D (esp. BetterC mode), and Nim. Even Julia & Go in the right context. Though honestly I often prefer wasting a few hundred bytes of RAM here and there, even on a microcontroller, for pure convenience. edit: forgot Odin. Another comment mentioned it, though I've never used it. It looks like it's used in production.
  - dralley 5y ago
    Zig has a few extra tricks up their sleeves compared to most languages. The ones that come to mind are * MultiArrayList * arbitrary size-integers that make it easy to pack data very tightly * easy access to several special purpose allocators which reduce the need for strategies like reference counting
    - elcritch 5y ago
      Perhaps, though nothing there that's not been available for a while. To be fair Zig has integrated some of these features well. * MultiArrayList is convenient and easy to do in Rust, D, Nim. Odin seems built around it. * Arbitrary bit-size integers seem more gimmicky than anything and similar to struct bitfields in other languages (except Rust oddly). Most compilers don't even pack uint8/uint16's for performance reasons. * Special purpose allocators are a bit more interesting. Still they don't provide actual memory safety AFAICT and can have fragmentation and performance penalties. It'll be interesting to see larger Zig code bases emerge in different fields and see how the memory footprint compares in practice.
      - bonzini 5y ago
        What? 8- and 16-bit are never 32-bit aligned nor sized.
        elcritch 5y ago
        To clarify I meant comparing how int8/int16's are packed in structs vs struct bitfields. Can't recall about the stack rules. Here's more discussion: http://www.catb.org/esr/structure-packing/ http://www.catb.org/esr/structure-packing/ https://github.com/Twon/Alignment/blob/master/docs/alignment_in_C%2B%2B.md https://github.com/Twon/Alignment/blob/master/docs/alignment... Also ARM for example doesn't have 8/16 bit registers so int8 or int16 will use a 32bit register: https://stackoverflow.com/a/23716920 https://stackoverflow.com/a/23716920 Curiosity got to me, perhaps Zig had improved significantly. So I compared the first benchmark I found (kostya/benchmarks/bf) with Zig with Nim. For the smaller input (bench.b) Zig did run with ~22% less RAM (about 20kB less). However, for the larger input (mandel.b) Nim+ARC used ~33% less RAM in safe mode: Nim 2.163mb -d:release; Zig 2.884mb -O ReleaseSafe; Zig 2.687mb -O ReleaseFast. The Nim requires 0.5mb less ram and the code is ~40% shorter. I don't have time to try out the Rust or Go versions though. edit: grammar
        dralley 5y ago
        Are the two using the exact same algorithm?
  - blippage 5y ago
    Odin doesn't work on 32-bit ARM, which was a disappointment to me.
    - elcritch 5y ago
      Bummer, looks like an intriguing language.
  - Tozen 5y ago
    In that category (of C/C++ alternatives) is also Vlang (https://vlang.io/ https://vlang.io/). It would be closer to Odin, than Julia, Go, or Nim. Although Vlang and Odin have a strong Go influence.

geodel 5y ago

Would you tell about those languages or they are left as an exercise to readers?

elcritch 5y ago
Sort of left it to the readers and hopefully encourage people to investigate for themselves. It's far too easy to get into "this benchmark vs this benchmark", etc. Memory usage is overall a complicated topic, which I think Andrew's comment doesn't do justice to. Granted the Zig team has done some impressive work, much of the memory usage & bloat in the C++ world comes from real world programs and libraries and the inevitable drift in program architecture over time. However, I could believe Zig's stdlib and culture encourages low memory footprints, but there isn't anything novel in the language that makes it inherently lower memory footprint. Though to name a few languages I'd say that can be directly comparable are Rust, D (esp. BetterC mode), and Nim. Even Julia & Go in the right context. Though honestly I often prefer wasting a few hundred bytes of RAM here and there, even on a microcontroller, for pure convenience. edit: forgot Odin. Another comment mentioned it, though I've never used it. It looks like it's used in production.
- dralley 5y ago
  Zig has a few extra tricks up their sleeves compared to most languages. The ones that come to mind are * MultiArrayList * arbitrary size-integers that make it easy to pack data very tightly * easy access to several special purpose allocators which reduce the need for strategies like reference counting
  - elcritch 5y ago
    Perhaps, though nothing there that's not been available for a while. To be fair Zig has integrated some of these features well. * MultiArrayList is convenient and easy to do in Rust, D, Nim. Odin seems built around it. * Arbitrary bit-size integers seem more gimmicky than anything and similar to struct bitfields in other languages (except Rust oddly). Most compilers don't even pack uint8/uint16's for performance reasons. * Special purpose allocators are a bit more interesting. Still they don't provide actual memory safety AFAICT and can have fragmentation and performance penalties. It'll be interesting to see larger Zig code bases emerge in different fields and see how the memory footprint compares in practice.
    - bonzini 5y ago
      What? 8- and 16-bit are never 32-bit aligned nor sized.
      - elcritch 5y ago
        To clarify I meant comparing how int8/int16's are packed in structs vs struct bitfields. Can't recall about the stack rules. Here's more discussion: http://www.catb.org/esr/structure-packing/ http://www.catb.org/esr/structure-packing/ https://github.com/Twon/Alignment/blob/master/docs/alignment_in_C%2B%2B.md https://github.com/Twon/Alignment/blob/master/docs/alignment... Also ARM for example doesn't have 8/16 bit registers so int8 or int16 will use a 32bit register: https://stackoverflow.com/a/23716920 https://stackoverflow.com/a/23716920 Curiosity got to me, perhaps Zig had improved significantly. So I compared the first benchmark I found (kostya/benchmarks/bf) with Zig with Nim. For the smaller input (bench.b) Zig did run with ~22% less RAM (about 20kB less). However, for the larger input (mandel.b) Nim+ARC used ~33% less RAM in safe mode: Nim 2.163mb -d:release; Zig 2.884mb -O ReleaseSafe; Zig 2.687mb -O ReleaseFast. The Nim requires 0.5mb less ram and the code is ~40% shorter. I don't have time to try out the Rust or Go versions though. edit: grammar
        dralley 5y ago
        Are the two using the exact same algorithm?
- blippage 5y ago
  Odin doesn't work on 32-bit ARM, which was a disappointment to me.
  - elcritch 5y ago
    Bummer, looks like an intriguing language.
- Tozen 5y ago
  In that category (of C/C++ alternatives) is also Vlang (https://vlang.io/ https://vlang.io/). It would be closer to Odin, than Julia, Go, or Nim. Although Vlang and Odin have a strong Go influence.