Comment by chaz72
21 hours ago
Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?
21 hours ago
Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?
Yes. For example in Rust it took a long time for floating point operations to be available at compile time and even now only a subset is. The reason is that a lot of energy and thought went into the issue of producing identical output (and what identical precisely means ) even when compilation is on a different processor than where the target runs.
As far as I know this is not a concern for Zig comptime.
Zig Comptime uses softfloat so it has architecture independent determinism.
And the zig core team is absolutely concerned with bitwise determinism in the compiled artifacts, iirc this is why they rejected the sloppy bun PR to the compiler.
Determinism and host/target agreement are two different properties.
The Zig core team is apparently not concerned enough about the second point to forbid transcendentals at comptime and this is something that'd be hard to take back, because I'd break existing code.
1 reply →
there has been a ton of work on making comptime a pure and deterministic execution environment. I do not expect that work to stop. I don't know where you are getting the idea that it is not an important design consideration for the language.
to expand, if two different host platforms cross compiling to the same target platform have different results, I am almost certain that would be considered a compiler bug.
if you're pointing out that a runtime operation and a compile time operation might not agree, I'd be more interested in understanding when that would ever have any meaningful impact on anything. given the compilation is supposed to be deterministic, the difference can easily be addressed by comptime branching on target architecture in the rare case that it matters for your program.
Determinism and host/target agreement are two different properties. I meant the second one.
It's something Rust guarantees (without me having to take care of it e.g. by manually branching) and Zig does not.
8 replies →
In C++ as well, constexpr math introduced in C++23 has similar concerns regarding floating point accuracy.
What's your source for this? Comptime Zig code can do pointer casts and whatnot, all emulated as if run on the target bitness/endianness/etc. And any operations that are undefined on the target platform result in a compile error. I've never had an issue cross-compiling.
Endianness and pointer casts are the mechanical part and I would expect Zig to emulate them correctly.
Other parts, like floats are harder. This is where a difference shows. Rust is like: "Sorry, since we cannot uphold our guarantees, no transcendentals for you at comptime ", whereas Zig is chill about that and let you have your transcendentals even if results may differ between comptime and runtime. Different mindsets.
4 replies →
Now I see this response, I responded to the other comment.
I assumed that it meant that if you ran code at compile time or at runtime, the results should be exactly the same given the same inputs.
And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.
Traditional stuff in this space are:
* floating point differences between the build machine and the target. By far the most common
* endiannes - code assumes little median runs on big endian
There’s other more subtle issues that can crop up but those are the big two.
Not saying I agree though - those can happen anyway when you run on two different machines anyway.
12 replies →
sin(x) can produce different results at comptime and runtime. In Rust there is no sin(x) at comptime for precisely this reason.
1 reply →