11 ms·

Hello HN! Here is some context to decorate this announcement: The Zig self-hosted compiler codebase consists of 197,549 lines of code. There are several diffe

• icsa 5y ago
  > uses significantly less memory, and represents a modest performance improvement. The reduced memory has significant value. Being able to do the same build on less expensive hardware or do more with the same hardware is a significant financial performance improvement
  • joshbaptiste 5y ago
    yup 18x memory reduction improvement 8.5GB -> 0.5GB according to the vid..
• erwincoumans 5y ago
  Congratulations with the milestone! Does using Zig over C++ lead to "less memory, and represents a modest performance"? Or was the C++ implementation a bit sloppy? (lacking data oriented design for instance) Also, what specifically are you most excited using Zig for?
  • AndyKelley 5y ago
    Thanks :) The new Zig implementation is certainly more well designed than the C++ implementation, for several reasons: * It's the second implementation of the language * It did not have to survive as much evolution and language churn * I leveled up as a programmer over the last 7 years * The Zig language safety and debugging features make it possible to do things I would never dream of attempting in C++ for fear of footguns. A lot of the data-oriented design stuff, for example, makes use of untagged unions, which are nightmarish to debug in C++ but trivial in Zig. In C++, accessing the wrong union field means you later end up trying to figure out where your memory became corrupted; in Zig it immediately crashes with a stack trace. This is just one example. * Zig makes certain data structures comfortable and ergonomic such as MultiArrayList. In C++ it's too hard, you end up making performance compromises to keep your sanity. Generally, I would say that C++ and Zig are in the same performance ballbark, but my (obviously biased) position is that the Zig language guides you away from bad habits where as C++ encourages them (such as smart pointers and reference counting). 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. Some of the projects I am exited to use Zig for: * rewriting Groove Basin (a music player server) in zig and adding more features * a local multiplayer arcade game that runs bare metal on a raspberry pi * a Digital Audio Workstation
    • maleldil 5y ago
      Thanks for the detailed answer! I have more questions, if you'll indulge me: If I understood it correctly, you think smart pointers and reference counting are bad habits. Why? Especially the smart pointers bit. Why does Zig use less memory than other languages? Is it inherent to Zig, or can it be reproduced in other languages?
      • lupire 5y ago
        I think Zig prefers explicit memory management, because allocations may fail and should be handled explicitly, and because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments). These are things that a "systems language" programmer should put in the work to do correctly/near-optimally, and not ask the compiler to just do something "good enough", like Python would.
• carapace 5y ago
  Congratulations!
• geophertz 5y ago
  > written in Zig instead of C++, uses significantly less memory, and represents a modest performance improvement That's particularly interesting considering the rust compiler in rust has never been as fast as the original OCaml one
  • sanxiyn 5y ago
    Well, OCaml Rust compiler also didn't use LLVM and used its own lightweight code generator and I think self-hosted Rust compiler frontend was in fact faster than OCaml Rust compiler frontend.
    • parentheses 5y ago
      With both projects, how much of the improvement is simply building for the second time?
      • sanxiyn 5y ago
        For Rust, I think improvement was almost entirely due to LLVM producing faster code. That's not applicable to Zig case, since both old and new compiler use LLVM. I don't know enough about Zig to answer.
  • est31 5y ago
    I wonder how much this statement still holds. I've never used the OCaml bootstrap compiler but performance wise, the rust compiler has improved incredibly since the 1.0 release.
    • sanxiyn 5y ago
      An apple to apple comparison is impossible because rustboot compiled a very different language. But I suspect suitably updated rustboot would be still faster because compilation time is dominated by LLVM.
      • pcwalton 5y ago
• dleslie 5y ago
  Happy to see the C backend coming along. LLVM is a major barrier to use on esoteric embedded devices.
  • sitkack 5y ago
    You can also target C through Wasm. https://github.com/WebAssembly/wabt/tree/main/wasm2c https://github.com/WebAssembly/wabt/tree/main/wasm2c
    • exikyut 5y ago
      My genuine question is what sort of code-size and/or performance impact the translation imposes. The simple example in the README.md seems straightforward enough, but I wonder if there are any pathological explosions in practice.
      • sitkack 5y ago
        That would be an interesting undergraduate paper. Perf, Size, by primary language, by toolchain, linker, post processor (dead code elimination, etc). For a pathological explosion, you mean something like a Zip Bomb? Wasm and C are pretty close together in their semantics, Wasm hides the stack and prevents jumping into the middle of a function (CFI, Control Flow Integrity). I think the code bloat should be on the order of some multiple of the smallest interpreter. I just did a quick scan of Wasm interpreters (3 in Rust, 1 in C) yblein/rust-wasm ~4kloc rhysd/wain ~16kloc paritytech/wasmi ~25kloc wasm3/wasm3 ~22kloc (C) My hunch is that the expanded code would be approximately (2x-5x interpreter + bin.wasm). I just did a spot check with doom.wasm, I am wrong. The resulting expanded C code when compiled to Arm is 2x the wasm binary size. 4.1M wasidoom.o 1.8M wasidoom.wasm https://en.wikipedia.org/wiki/Zip_bomb https://en.wikipedia.org/wiki/Zip_bomb
• riffraff 5y ago
  it's so surprising to hear there was a Zig Meetup in Milan, I'd not expect a large enough community to exist there, pretty cool!
  • vanderZwan 5y ago
    Probably a significant chunk of the larger European community was represented there too - don't forget that traveling to EU countries is relatively easy for EU citizens
• einpoklum 5y ago
  * What kind of tests are these "behavior test"? * Is that a list of compilation targets? * If not all behavior tests pass, does that not mean that the compiler fails to compile programs correctly? Please indulge those of us who are not familiar with self-hosting compiler engineering.
  • Spex_guy 5y ago
    > What kind of tests are these "behavior test"? Snippets of zig code that use language features and then make sure those features did the right thing. You can find them here: https://github.com/ziglang/zig/tree/master/test/behavior https://github.com/ziglang/zig/tree/master/test/behavior > Is that a list of compilation targets? Mostly. Pedantically, it's a list of code generation backends, each of which may have multiple compilation targets. So for example the LLVM backend can target many architectures. The ones that are architecture specific are currently debug-only and cannot do optimization. > If not all behavior tests pass, does that not mean that the compiler fails to compile programs correctly? Some tests are not passing because they cause an incorrect compile error, others compile but have incorrect behavior (miscompilation). Don't use Zig in production yet ;) (edit: fix formatting)
    • kristoff_it 5y ago
      To add to what Spex said: also some of those tests check language features that the compiler code doesn't exercise, like async/await. This means that the compiler is able to build itself, but is not able to build every possible valid Zig program. We're getting there though :^)