PixelGuys
Should the `run` scripts compile in ReleaseSafe instead of ReleaseFast?
Advantages:
- more and better debug info if a crash occurs
- undefined behavior, which could lead to subtle errors, is likely catched earlier
Disadvantages:
- potentially more crashes instead for things that previously would have worked mostly fine
- lower performance
No, not in an easy way. We can disable safety checks in performance critical functions with @setRuntimeSafety(false) though.
Also I should probably check if the performance impact even is that big.
See also:
@setFloatMode(comptime mode: FloatMode) void
Changes the current scope's rules about how floating point operations are defined.
This is equivalent to -ffast-math in GCC```
Is this the only way to enable fast math?
I just compared the two release mode and loading a render distance 12 world goes from 33.5 s to 40 s, so a 20% increase in runtime. Overall I'd say it's not too bad for the potential benefit it gets us. I would need to fix #410 first though.
Can you profile with fast math and stuff? Also, how do you profile Cubyz? I used this, but it feels like a hack.
if(self.size == 0) {
if(main.game.world != null and main.game.world.?.gameTime.load(.monotonic) > 0)
main.Window.c.glfwSetWindowShouldClose(main.Window.window,main.Window.c.GLFW_TRUE);
}
Also, how do you profile Cubyz?
In this case, I just used the timer of my phone xD
Not sound :(
My hack is better. You can do time ./zig-out/bin/Cubyzig.
time is actually worse at measuring this, because it also measures the time that is spent in the menu.
Right, I guess I could use that as well, still, apart from being more precise, it wouldn't actually be much different from using my phone.
Good to know performance is in good hands. I could get time within ±0.1s out of 8.9 (lods=3).
There are only a few instances where this would help finding bugs, and the longer compile times and runtimes are not really worth it in my opinion, So I have decided not to do this,
I think this should be reconsidered, since it would help a lot for detecting and fixing bugs. But it would be nice if we could somehow pipe the output into a log file as well.
It seems that Zig 14.0 moves GPA into DebugAllocator and adds the "for ReleaseFast" SmpAllocator. GPA/DebugAllocator implies stack traces and optional safety features. SmpAllocator has neither traces nor safety but is faster (I do not have benchmarks). Previously we used GPA without safety features.
Enabling DebugAllocator+safety for debug scripts is a no-brainer. This is what we have now.
For release scripts, we have the options of DebugAllocator+safety (equivalent to switching to ReleaseSafe in Zig 13.0), DebugAllocator-safety (current), and SmpAllocator.
I feel like most people would want SmpAllocator for themselves, until they find the rare heisenbug and can't report it properly. If these bugs are common, perhaps DebugAllocator should be the default. Perhaps there should be some way to opt out in favor of SmpAllocator (vi src/main.zig, or by passing ReleaseFast in the commandline). If we start accepting compile flags in general, it might be useful to save them to a file like build-type for reporting.
TL;DR Based on the previous message, Cubyz should use DebugAllocator when Zig 14.0 comes around.
Usual the types of bugs, that the DebugAllocator catches (→use-after-free and leaks and double frees), are easily caught in debug mode during development. What I'm interested in are mainly assertion failures and just simply getting stack traces for segfaults.