3 ms·

I get inconsistent results, both in terms of platform and language. The benchmark may be flawed, and no conclusions should be drawn, to be prudent. Running on

I get inconsistent results, both in terms of platform and language. The benchmark may be flawed, and no conclusions should be drawn, to be prudent. Running on Linux (zig -Dc), rounded average of 3 runs. 8-thread Intel laptop machine: zip 0.9.0-dev.958: 945 rust 1.5.0-nightly 21-09-12/qsort: 545 rust 1.5.0-nightly 21-09-12/rsort: 255 go 1.16.8: 355 32-thread AMD workstation: zip 0.9.0-dev.958: 410 rust 1.5.0-nightly 21-09-12/qsort: 780 rust 1.5.0-nightly 21-09-12/rsort: 135 go 1.16.8: 135 Additionally, I haven't done a thorough review, but enabling the commented code: // Optimized version (hooks directly into the scheduler) // rayon::join( // || quick_sort(low), // || quick_sort(high) // ); yields a 110ms run on the faster machine.

kprotty 5y ago
I'm not sure how this implies it is flawed. It benchmarks thread pools so on a system which allowed more parallel concurrent tasks (i.e. 32t amd cpu) the throughput is expected to scale somewhat, and you see this in your results. Also, `zig -Dc` links to libc (`-Dc`) but builds in debug mode by default, similar to Rust and C/C++ compilers. The readme contains instructions to compile it with optimizations (`-Drelease-fast`), the rust versions do so as well (`--release`) so you should re-evaluate your results. See one of my other comments in this post on why I didn't use rayon::join() by default.
- pizza234 5y ago
  > Also, `zig -Dc` links to libc (`-Dc`) but builds in debug mode by default, similar to Rust and C/C++ compilers Right! This was a misunderstanding of mine. Updated results: 8-thread Intel laptop machine: zip 0.9.0-dev.958: 230 rust 1.5.0-nightly 21-09-12/qsort: 545 rust 1.5.0-nightly 21-09-12/rsort: 255 go 1.16.8: 355 32-thread AMD workstation: zip 0.9.0-dev.958: 125 rust 1.5.0-nightly 21-09-12/qsort: 780 rust 1.5.0-nightly 21-09-12/rsort: 135 go 1.16.8: 135 The reason why I think that conclusions should not be drawn due to the excessive variability between systems. On the parent poster's system, zig is faster by a much larger margin than the two systems I've tried. And there's a ~45% difference in Go's performance compared to the fastest runner for the respective system.
  - kprotty 5y ago
    The results will vary on different systems given how the combination of the CPU and OS handle thread synchronization + scheduling. On one of my desktops running Windows 10 with an i7-4790k, the Go qsort runs slower (~600ms) than the Rust qsort (~490ms) while on Linux systems the results are generally the opposite. The zig thread pool appears consistently faster for this benchmark on different systems, and rayon::join appears consistently faster than the zig thread pool on different systems too. I believe you can somewhat conclude the advantages of their designs from this relative to each other rather than in an absolute sense.

kprotty 5y ago

I'm not sure how this implies it is flawed. It benchmarks thread pools so on a system which allowed more parallel concurrent tasks (i.e. 32t amd cpu) the throughput is expected to scale somewhat, and you see this in your results. Also, `zig -Dc` links to libc (`-Dc`) but builds in debug mode by default, similar to Rust and C/C++ compilers. The readme contains instructions to compile it with optimizations (`-Drelease-fast`), the rust versions do so as well (`--release`) so you should re-evaluate your results. See one of my other comments in this post on why I didn't use rayon::join() by default.

pizza234 5y ago
> Also, `zig -Dc` links to libc (`-Dc`) but builds in debug mode by default, similar to Rust and C/C++ compilers Right! This was a misunderstanding of mine. Updated results: 8-thread Intel laptop machine: zip 0.9.0-dev.958: 230 rust 1.5.0-nightly 21-09-12/qsort: 545 rust 1.5.0-nightly 21-09-12/rsort: 255 go 1.16.8: 355 32-thread AMD workstation: zip 0.9.0-dev.958: 125 rust 1.5.0-nightly 21-09-12/qsort: 780 rust 1.5.0-nightly 21-09-12/rsort: 135 go 1.16.8: 135 The reason why I think that conclusions should not be drawn due to the excessive variability between systems. On the parent poster's system, zig is faster by a much larger margin than the two systems I've tried. And there's a ~45% difference in Go's performance compared to the fastest runner for the respective system.
- kprotty 5y ago
  The results will vary on different systems given how the combination of the CPU and OS handle thread synchronization + scheduling. On one of my desktops running Windows 10 with an i7-4790k, the Go qsort runs slower (~600ms) than the Rust qsort (~490ms) while on Linux systems the results are generally the opposite. The zig thread pool appears consistently faster for this benchmark on different systems, and rayon::join appears consistently faster than the zig thread pool on different systems too. I believe you can somewhat conclude the advantages of their designs from this relative to each other rather than in an absolute sense.