5 ms·

Just a quick glance at you repo, and I'm noticing you're running Zig `zig build -fstage1 -Drelease-fast=true` and Rust `cargo run --release` with the release fl

Just a quick glance at you repo, and I'm noticing you're running Zig `zig build -fstage1 -Drelease-fast=true` and Rust `cargo run --release` with the release flags on. You should do the same for Nim `nimble build -d:release --opt:speed`; Go too.

Shish2k 4y ago
Updating nim’s compiler flags, seems to be ~4x faster now :D nim: Emulated 600 frames in 0.44s (1367fps) Do you happen to know the right flags for release-mode Go? Last time I checked (admittedly years ago) I thought they just had the one “reasonably fast and reasonably debuggable” build mode
- Thaxll 4y ago
  There is no release flag for Go.
  - throwaway894345 4y ago
    To elaborate, Go is always in release mode because release compiles are about as fast as other languages' debug modes.
    - LukeShu 4y ago
      I'd phrase that as "release mode by default", not "always in release mode". There are various debug things you can turn on, such as the race detector, the memory sanitizer, or coverage tracking.
- plainOldText 4y ago
  I do not, sorry. I'm sure some Go developer can chime in.
- cb321 4y ago
  With Nim `nimble build -d:danger -d:lto --passC:-march=native` I just got 1920 frames/s while with your rust build only 1237 fps on the same machine (EDIT: and 1307 frames/s with C++.)
  - plainOldText 4y ago
    In that case, did you also run rust with the equivalent RUSTFLAGS="-C target-cpu=native"? :) Perhaps benchmarks should be compared on equal footing, say, with the default release flag or all optimizations turned on, otherwise they're improper.
    - cb321 4y ago
      I tried. That actually made the rust slower for me (i7-6700k, gcc-12.2, rustc-1.64). 1180 frames/s. And without the -march=native the Nim was at 1620. And it also did not help the C++ branch (but helped Nim about 1.2x). But really the original author/poster should do some set on his box. I cannot even compile/run all his things. The point of my comment was just to give a reference for how far off impressions can be from build flags. PGO (available to Nim, c++, but maybe not to Rust yet?) is a whole other set of maybe nothing burgers or maybe big improvements. (But, btw, I could not agree more that all experiments in this entire general space should have various big, bold disclaimers. Over-concluding from these things is rampant.)
      - plainOldText 4y ago
        Yes, tweaking the compiler flags can alter the performance substantially. I'm glad to see Nim so fast though.
        cb321 4y ago
        And with the author's hot off the presses nim flags I get only 1464 fps. So, 1920/1464 = 1.31 for my nim compile flags vs. his new ones, only a little less than the 2521/1626 that was interesting people. For something super jumpy like a simulator, I would find it unsurprising for PGO to make up (or surpass) the difference to Zig in both Nim and C++. 20 years ago there was this ACOVEA [1] project to try to discover great sets of gcc flags that could often find 2X improvements in object code speed for me. The range from build flags/procedures is often much greater than the supposedly interesting cross-language variation. These things often more measure developer experience/persistence than something intrinsic (and build flags/procedures are only part of that experience/persistence). [1] https://github.com/Acovea/libacovea https://github.com/Acovea/libacovea
streblo 4y ago
Is there such a thing for go?
- LukeShu 4y ago
  It's the default for Go; with Go you have to explicitly turn on the debug features that you want.

Shish2k 4y ago

Updating nim’s compiler flags, seems to be ~4x faster now :D nim: Emulated 600 frames in 0.44s (1367fps) Do you happen to know the right flags for release-mode Go? Last time I checked (admittedly years ago) I thought they just had the one “reasonably fast and reasonably debuggable” build mode

Thaxll 4y ago
There is no release flag for Go.
- throwaway894345 4y ago
  To elaborate, Go is always in release mode because release compiles are about as fast as other languages' debug modes.
  - LukeShu 4y ago
    I'd phrase that as "release mode by default", not "always in release mode". There are various debug things you can turn on, such as the race detector, the memory sanitizer, or coverage tracking.
plainOldText 4y ago
I do not, sorry. I'm sure some Go developer can chime in.
cb321 4y ago
With Nim `nimble build -d:danger -d:lto --passC:-march=native` I just got 1920 frames/s while with your rust build only 1237 fps on the same machine (EDIT: and 1307 frames/s with C++.)
- plainOldText 4y ago
  In that case, did you also run rust with the equivalent RUSTFLAGS="-C target-cpu=native"? :) Perhaps benchmarks should be compared on equal footing, say, with the default release flag or all optimizations turned on, otherwise they're improper.
  - cb321 4y ago
    I tried. That actually made the rust slower for me (i7-6700k, gcc-12.2, rustc-1.64). 1180 frames/s. And without the -march=native the Nim was at 1620. And it also did not help the C++ branch (but helped Nim about 1.2x). But really the original author/poster should do some set on his box. I cannot even compile/run all his things. The point of my comment was just to give a reference for how far off impressions can be from build flags. PGO (available to Nim, c++, but maybe not to Rust yet?) is a whole other set of maybe nothing burgers or maybe big improvements. (But, btw, I could not agree more that all experiments in this entire general space should have various big, bold disclaimers. Over-concluding from these things is rampant.)
    - plainOldText 4y ago
      Yes, tweaking the compiler flags can alter the performance substantially. I'm glad to see Nim so fast though.
      - cb321 4y ago
        And with the author's hot off the presses nim flags I get only 1464 fps. So, 1920/1464 = 1.31 for my nim compile flags vs. his new ones, only a little less than the 2521/1626 that was interesting people. For something super jumpy like a simulator, I would find it unsurprising for PGO to make up (or surpass) the difference to Zig in both Nim and C++. 20 years ago there was this ACOVEA [1] project to try to discover great sets of gcc flags that could often find 2X improvements in object code speed for me. The range from build flags/procedures is often much greater than the supposedly interesting cross-language variation. These things often more measure developer experience/persistence than something intrinsic (and build flags/procedures are only part of that experience/persistence). [1] https://github.com/Acovea/libacovea https://github.com/Acovea/libacovea

streblo 4y ago

Is there such a thing for go?

LukeShu 4y ago
It's the default for Go; with Go you have to explicitly turn on the debug features that you want.