5 ms·

Trying to understand the Zig goals a bit better.. If you care about compilation speed b/c it's slowing down development - wouldn't it make sense to work on an

• IshKebab 1y ago
  I wouldn't say games are a corner case.
  • dontlaugh 1y ago
    For games you have to compile release builds almost all the time anyway, otherwise performance wouldn’t be playable.
    • flohofwoe 1y ago
      That's only true for badly written game code though ;) Even with C++ and heavy stdlib usage it's possible to have debug builds that are only around 3..5 times slower than release builds in C++. And you need that wiggle room anyway to account for lower end CPUs which your game should better be able to run on.
      • dontlaugh 1y ago
        If you target consoles, you’re already on the lowest end hardware you’ll run on. It’s extremely rare to have much (if any) headroom for graphically competitive games. 20% is a stretch, 3x is unthinkable.
        • flohofwoe 1y ago
          Then I would do most of the development work that doesn't directly touch console APIs on a PC version of the game and do development and debugging on a high-end PC. Some compilers also have debug options which apply optimizations while the code still remains debuggable (e.g. on MSVC: https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-optimized-code?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/how-...) - don't know about Sony's toolchain though. Another option might be to only optimize the most performance sensitive parts while keeping 90% of the code in debug mode. In any case, I would try everything before having to give up debuggable builds.
          • dontlaugh 1y ago
            It doesn’t matter. You will hit (for example) rendering bugs that only happen on a specific version of a console with sufficient frequency that you’ll rarely use debug builds. Debug builds are used sometimes, just not most of the time.
          • pjmlp 1y ago
            That only kind of works when not using console specific hardware. Naturally you can abstract them as middleware does it, however it is where tracking performance bugs usually lies.
      • geokon 1y ago
        Just curious - is this from personal experience? I've never done it, but I just find it hard to believe the slow down would be that large. Most of the computation is on GPU, and you can set your build up such that you link to libraries built at different compilation optimizations.. and they're likely the ones doing most of the heavy lifting. You're not rebuilding all of the underlying libs b/c you're not typically debugging them. EDIT: if you're targeting a console.. why would you not debug using higher end hardware? If anything it's an argument in favor of running on an interpreter with a very high end computer for the majority of development..
        • flohofwoe 1y ago
          Yeah, around 3x slower is what I've seen when I was still working on reasonably big (around a million lines of 'orthodox C++' code) PC games until around 2020 with MSVC and without stdlib usage. This was building the entire game code with the same build options though, we didn't bother to build parts of the code in release mode and parts in debug mode, since debug performance was fast enough for the game to still run in realtime. We also didn't use a big integrated engine like UE, only some specialized middleware libraries that were integrated into the build as source code. We did spend quite some effort to keep both build time and debug performance under control. The few cases were debug performance became unacceptable were usually caused by 'accidentially exponential' problems. > Most of the computation is on GPU Not in our case, the GPU was only used for rendering. All game logic was running on the CPU. IIRC the biggest chunk was pathfinding and visibility/collision/hit checks (e.g. all sorts of NxM situations in the lower levels of the mob AI).
          • geokon 1y ago
            Ah okay, then that makes sense. It really depends on your build system. My natural inclination would be to not have a pathfinding system in DEBUG unless I was actively working on it. But it's not always very easy to set things up to be that way
        • TinkersW 1y ago
          The slowdown can be enormous if you use SIMD, I believe MSVC emits a write to memory after every single SIMD op in debug, thus the code is incredibly slow(more than 10x). If you have any SIMD kernels you will suffer, and likely switch to release, with manual markings used to disable optimizations per function/file.
      • pjmlp 1y ago
        And if using Visual Studio, it is even possible to debug release builds, with dynamic debugging feature.
    • chongli 1y ago
      This is why games ship interpreters and include a lot of code scripting the gameplay (e.g in Lua) rather than having it all written in C++. You get fast release builds with a decent framerate and the ability to iterate on a lot of the “business logic” from within the game itself.
• delusional 1y ago
  > Compiling for executable-speed seems inherently orthogonal to compilation time That true at the limit. As is often the case there's a vast space in the middle, between the extremes of ultimate executable speed and ultimate compiler speed, where you can make optimizations that don't trade off against each other. Where you can make the compiler faster while producing the exact same bytecode.
  • Ygg2 1y ago
    Limits are more important than implied. Language benchmarks, computer game performance.
• weinzierl 1y ago
  "Trying to understand the Zig goals a bit better.. If you care about compilation speed b/c it's slowing down development - wouldn't it make sense to work on an interpreter?" I've heard Rust classified as Safety, Performance, Usability in that order and Zig as Performance, Usability, Safety. From that perspective the build speed-ups make sense while an interpreter would only fit a triple where usability comes first.
  • ModernMech 1y ago
    I don't think it's right to say Zig is more performance-focused than Rust. Based on their designs, they should both be able to generate similar machine code. Indeed, benchmarks show that Rust and Zig perform very similarly: https://programming-language-benchmarks.vercel.app/rust-vs-zig https://programming-language-benchmarks.vercel.app/rust-vs-z... This is why the value proposition of Zig is a question for people, because if you got measurably better performance out of Zig in exchange for worse safety that would be one thing. But Rust is just as performant, so with Zig you're exchanging safety for expressivity, which is a much less appealing tradeoff; the learning from C is that expressivity without safety encourages programmers to create a minefield of exploitable bugs.
    • logicchains 1y ago
      It's much easier to write ultra low latency code in Zig because doing so requires using local bump-a-pointer allocators, and the whole Zig standard library is built around that (everything that allocates must take the allocator as a param). Rust on the other hand doesn't make custom allocators easy to use, partially because proving they're safe to the borrow checker is tricky.
    • toshinoriyagi 1y ago
      I don't think Zig is about expressivity over safety. Many people liken Zig to C, like with Rust to C++. Zig is a lot safer than C by nature. It does not aim to be as safe as Rust by default. But the language is a lot simpler. It also has excellent cross-compiling, much faster compilation (which will improve drastically as incremental compilation is finished), and a better experience interfacing with/using C code. So there are situations where one may prefer Zig, but if memory-safe performance is the most important thing, Rust is the better tool since that is what it was designed for.
• Quitschquat 1y ago
  > wouldn't it make sense to work on an interpreter I like the Julia approach. Full on interactivity, the “interpreter” just compiles and runs your code. SBCL, my favorite Common Lisp, works the same way I think
  • geokon 1y ago
    thanks for bringing up Julia! I totally forgot it exists. Its really dropped off the HNniverse. Wonder why.. havent seen it mentioned in like a couple of years