I've been working on incremental compilation in Zap for the past few days. Zap does a pre-compilation step to highly optimize what it passes to Zig's compiler as Zig IR. This meant very fast runtime and small binaries at the cost of super slow compilation times. I've refactored Zap's build steps to now respect Zig's own optimize flags like releaseFast, releaseSafe, debug, etc... and this has knocked down Zap's own test suite (Zest) compilation time from 3 miniutes to about 10 seconds. Still slower than I would like so now I'm looking into incremental rebuilds. First compilation is painful but after that small changes shouldn't force a full recompile.

Got doom working on smol machines today: github.com/smol-machines/smo… try it with these commands: ``` smolvm microvm create --net --mem 2048 doom smolvm microvm start doom Then reinstall Zig and rebuild: smolvm microvm exec --name doom -- sh -c "apk add xz curl tar git && \ curl -L -o /tmp/zig.tar.xz 'ziglang.org/download/0.15.2/…' && \ cd /tmp && tar xf zig.tar.xz && \ ln -sf /tmp/zig-aarch64-linux-0.15.2/zig /usr/local/bin/zig && \ git clone github.com/cryptocode/termin… && \ cd terminal-doom && zig build -Doptimize=ReleaseFast -Dsound=false" smolvm microvm exec --name doom -it -- sh -c "cd /tmp/terminal-doom && ./zig-out/bin/terminal-doom" ```

Voltaire is capable of another 20% to 30% faster perf by building with ReleaseFast rather than the default ReleaseSmall shown in these benchmarks

i got my 112 integration tests down to 1.3 mins. helps to compile zig "ReleaseFast"

I used the ReleaseFast flag and updated the benchmark to print the actual CPU it's running on instead of the hard coded string. The results are even more impressive: Platform: Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40GHz Config: 500M msgs/producer, batch=32768, ring=64K slots ┌─────────────┬───────────────┬─────────┐ │ Config │ Throughput │ Status │ ├─────────────┼───────────────┼─────────┤ │ 1P1C │ 15.02 B/s │ ✗ LOW │ │ 2P2C │ 30.24 B/s │ ○ OK │ │ 4P4C │ 60.23 B/s │ ✓ PASS │ │ 6P6C │ 84.10 B/s │ ✓ PASS │ │ 8P8C │ 99.85 B/s │ ✓ PASS │ └─────────────┴───────────────┴─────────┘

For Guillotine ReleaseFast is fast ReleaseSmall is small But why should you not use them? Because the coolest mode is ReleaseSafe mode: The Tracer is currently a zero-cost abstraction for plugging into the EVM, but it’s about to become a full sidecar and event system. Soon, every EVM action will emit events you can: - Log for tracing and visibility - Pause/modify state at runtime (debuggers) - Understand optimizations like opcode fusion - Independently validate execution - Add safety features (e.g. loop limits) The new DefaultTracer will go beyond simple traces. It will independently validate execution in real time, ensuring: - PC advances correctly - Gas estimates match expectations - Stack, memory, and storage update correctly - System Memory allocation is in reasonable ranges for the bytecode size All with zero performance cost in ReleaseSmall and ReleaseFast. As you run guillotine in the wild in ReleaseSafe mode, you will literally be executing unit tests in real time giving us confidence Guillotine is doing what we expect. This will give Guillotine the visibility, safety, and debuggability it needs to move from alpha to beta.

-Doptimize=ReleaseFast stupid autocorrect

i process stuff faster in debug mode now than I ever did with -ReleaseFast in vanilla version 💀

the idea is for build.zig to replace cmake...you know how horrible cmake are. if it's only gcc -o hello -O hello.c then the Zig's equivalent is: zig build-exe -O ReleaseFast hello.zig ~ both are equally easy. Now compare build.zig with cmake..

For multifile builds check the Zig directory of my following repository. This project has only 2 files but using: const grid = @​import("grid.zig"); in sudoku.zig, Zig will compile both files just typing: zig build-exe -O ReleaseFast sudoku.zig github.com/nilostolte/Sudoku

We're currently using ReleaseFast: github.com/defold/defold/blo… Interestingly, due to vendor restrictions, we need to move to generating .c files. Not sure if that will affect the Fast/Small options. I guess it should? 🤔

not exactly crash, Debug and ReleaseSafe turns it into panic, ReleaseFast turns it into UB. so its sanitised UB

I think that at the end you will get an if else in ReleaseFast (not sure about ReleaseSafe) but at comptime you get the check for exhaustivness. What you will end up with in Rust?

releasefast and wasi, repo is here: github.com/mattn/wasi-benchm…

We forgot to enable “ReleaseFast” mode in bun for windows. It’s using “ReleaseSafe” which adds bounds checks and has non-trivial performance overhead so I guess Bundows will get faster in v1.1.1

𝗭𝗶𝗴 𝗦𝘂𝗱𝗼𝗸𝘂 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝘁𝗶𝗺𝗶𝗻𝗴. Code compiled with the build command: zig build-exe -O ReleaseFast grid.zig 993 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗰𝗼𝗻𝗱𝘀 is the record of speed to solve this grid with no optimization done by hand. Not even in C I got such a low time! 👇

ここでzig捨てとくべきなんじゃないかと思ってgcc jumpをrustにしてみたんだけれど、実行バイナリのサイズが違うな。rustはltoとかoptimize zとかつけてみても4.3M →2.1Mにしかならなかったけれど、ReleaseFast 1.8M → ReleaseSmall 17K になる

github.com/GoWind/1brc/tree/… 6.7 seconds with 12 threads on an M2Pro using #zig and -Doptimize=ReleaseFast. Got a shock when optimize=Debug took 57secs in the first run. My memory allocations are all over the place, pretty sure some Zig ace can optimize it to be much faster !

Just compile with `zig build -Doptimize=ReleaseFast -Dtarget=aarch64-windows`. This is how all the .NET packages are made. It’s also documented: libsodium.gitbook.io/doc/ins…

Releaseにしないと最適化かからないし、ReleaseSafeでもレンジチェックとかのこるはず。 ReleaseFastだとレンジチェック吹っ飛ばすんじゃなかったっけ。