a zig lane, the C++ lane as a C++ program per test, a startup table, and fresh macOS and Linux records

[borisbat]

Behavior change: every test is pure das now, the C++ lane is a C++ program per test under tests/cpp/, test_profile.cpp is the interop module only (AddOne, ParseFloat), a capture writes a third section, Startup, and the records are a fresh macOS capture (M1 Max) and a new Linux one (zen4); the old Windows record is removed.

Why. The suite's native floor was C++ alone, measured through a das loop and a binding call per iteration; a startup report compared us against zig; and nothing measured what a program in each lane pays before its first line.

What changes.

• tests/zig/<test>.zig for all sixteen tests plus profile.zig, the shared budget loop; built on demand with zig build-exe -O ReleaseFast into tests/zig/.zig-out; ZIG after C++ on the AOT or JIT board.
• tests/cpp/<test>.cpp for all sixteen tests plus profile.h, the same budget loop; built at the configuration's default optimization (Release -O3, MSVC /O2, what the kernels had as a module) and staged into the runtime root beside the other lanes' hosts; run_files spawns the staged program like every other lane. native links addOne.c as its own object. The tests no longer require testProfile (interop host calls keeps it - its das kernel calls AddOne), and the module shrinks from 1258 lines to the two interop callees, each bound NTTP-inline and member.
• --startup, and every --json capture: hello world in every language on the boards, launched the way that lane's kernels are launched - the das interpreter, the JIT with a warm DLL cache, a das exe built into a temp directory, the C++ hello, the zig hello, Luau with and without --codegen, Lua, LuaJIT with and without the JIT, Quirrel, QuickJS, Mono under both engines from an mcs build, .NET from a dotnet build - ten launches after a warm one, the median and the samples, and the size of the artifact where the lane runs one it built.
• The .NET builds run with UseSharedCompilation=false: a build left the Roslyn compiler server resident across the lanes measured after it.
• profile_root reads the cwd tree the way config.das does: get_this_module_dir() for a relative main.das is the binary's directory, and the runner had been reading the SDK's staged copy of the tests.
• The README generator renders the Startup table one runtime per row and says what a row is; Zig joins the AOT or JIT columns and the runtime line.
• Records: profile_results_darwin.json recaptured on the M1 Max; profile_results_linux.json is new, from zen4 (Ryzen 7 PRO 8700GE, Debian 12, clang-19 SDK from master); profile_results_windows.json, the Threadripper 3990X capture that predates all of this, is removed. The README carries macOS and Linux.

Observable behavior.

• Both boards carry a Zig column, the C++ column is the standalone programs, and a Startup table follows the two boards; the Windows section is gone until a Windows capture lands.
• M1 Max: das JIT geomean 0.75 of C++ and 0.93 of zig over the sixteen rows, das AOT 0.93 of C++, zig 0.81 of C++; das AOT or JIT fastest on nine rows of sixteen. Hello world: das interpreter 46 ms, das JIT 332 ms, das exe 12 ms (50 KB), C++ 5.7 ms, zig 6.1 ms, the Lua family, Quirrel and QuickJS 6 to 7.6 ms, Mono 21 to 25 ms, .NET 28 ms.
• zen4: das JIT geomean 0.72 of C++ and 1.02 of zig, das AOT 0.76 of C++, zig 0.71 of C++ (clang-19 at -O3 against zig's LLVM 22); das AOT or JIT fastest on eight rows. Hello world: das interpreter 61 ms, das JIT 423 ms, das exe 15 ms, C++ 6.1 ms, zig 6.0 ms, the Lua family and QuickJS 6 to 7 ms, Mono 16 to 18 ms, .NET 24 ms.
• The queen row reads two speeds on the M1 in every native lane, process by process (das JIT 28 to 56 us, C++ 38 to 62, zig 56 to 60), so its JIT, C++ and zig cells carry a 20 to 27 percent spread where the rest of the board sits at 0 to 2; the same programs on an M5 Max and on zen4 read one speed. A 64-byte aligned board does not change it, nor does the QoS class.

Where to look. collect_startup in main.das; run_files in config.das for the C++ and zig spawns; tests/cpp/profile.h and tests/zig/profile.zig - every kernel takes its size through a volatile read and drops its result into a volatile sink, or the optimizer deletes every call but the last and the budget loop spins on nothing (five of the C++ programs and four of the zig ones did exactly that before the sink).

Validation, claims, ledger

Validation

• Every zig and C++ program standalone and through the runner on an M5 Max, the M1 and zen4; each box's record is the second of two full captures there - the first M1 capture ran with Parsec's daemon up and carried one 6x sample on LuaJIT's tree row; the first zen4 capture carried one 1.7x sample in five in cells spread over every lane, the Roslyn build server resident across the run; the second captures are clean on every row but the M1's queen (above).
• On zen4 the das AOT lane's fifth in-process sample reads 1.7x on three rows (queen, interop host calls, fibonacci recursive) in both captures, the same three rows and the same factor; the medians are the fast four. Not chased.
• The C++ program column against the das-hosted module on the same M1: within a few percent on every row (sha256 156 vs 156 us, tree 2.51 vs 2.52 ms, fibonacci loop 2.02 vs 2.02 ms) except mandelbrot, 0.36 vs 0.57 ms - a scalar sqrtf against the module's vector length call.
• The first startup capture read 107 ms on every lane: a timed popen_argv polls the child on a 100 ms grain. The wait is unbounded now.
• Launches are timed from a daslang parent through popen_argv; the spawn adds about 2 ms to every lane alike.
• The SDK install was missing include/daScript/builtin/ast_gen.inc, which the shipped aot_builtin_ast.h includes; zen4's AOT companion did not build until the file was copied in by hand. Fixed in the SDK installs the generated binding tables the shipped aot_builtin_ast.h includes GaijinEntertainment/daScript#3963.

Claims - stated, not tested

• Windows: zig build-exe with the addOne.c object and -lc, the C++ programs and their staging, the startup capture's -jit-no-cache JIT lane, the PATH prefix for the das exe, and the mcs / dotnet build steps were not run on a Windows host.

Not done

• A Windows capture, when a Windows box frees up.