TeXitoi / benchmarksgame-rs

The Computer Language Benchmarks Game: Rust implementations

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

refactor

gnzlbg opened this issue · comments

As part of lolbench (rustc's run-time performance tracking) it might be better to refactor this crate into one crate per benchmark that use the normal Cargo.toml to fetch dependencies. This would allow each of the benchmarks to have their own benches, and make it more clear how to run them.

This is not how the benchmarksgame works, alas. Their requirement is one source file per benchmark plus one Makefile to build the benchmarks.

@llogiq we can make a workspace, with each benchmark crate being a member of the workspace. We can then add a root crate that checks that the benchmarks only have a single lib.rs, and generates a directory ready to export to the benchmarks game.

Either by parsing the Cargo.tomls and generating the Makefile, or by checking that a manually written Makefile is in sync with the Cargo.tomls.

Thanks. FWIW, the rust-lang-rust/packed_simd crate contains some of the benchmark game examples implemented using rayon+portable simd as "independent crates" (nbody, fannkuch-redux, mandelbrot, and I think that's it). Porting them to rayon+stable SIMD (x86 intel intrinsics) shouldn't be very hard; if somebody wants to do this, it could be done there and set as the "default" run mode for the benchmarks, that way one can compare the performance of the portable SIMD intrinsics vs the architecture specific ones.

@TeXitoi you can also argue that one advantage of Rust is how easy the build system and benchmarks are to use, but that due to how the benchmarks must be submitted, none of these features can be used while developing the benchmarks.

Isaac doesn't want to change something that is working for him.

@TeXitoi how did you read that from its response ? I mean, it appears to me that isaac is open to reevaluating the workflow, but it doesn't want to change it to something that's painful to him which is fair. We should try to find a solution that works for everybody. I think that Rust without cargo is not Rust.

I already tried some years ago. I don't have the time to argument on this topic. In practice, the audience don't really care as they don't look at the build process.

I'd really prefer to use cargo, thus, if you have the motivation, I let you argument. I will agree if needed.