Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose target-cpu=native as a profile setting #2535

Open
bluss opened this issue Mar 31, 2016 · 4 comments
Open

Expose target-cpu=native as a profile setting #2535

bluss opened this issue Mar 31, 2016 · 4 comments
Labels
A-profiles Area: profiles C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@bluss
Copy link
Member

bluss commented Mar 31, 2016

For a lot of projects you want that the compiler uses every cpu feature available. Not just numerics, but loops that copy or search in general can profit from using wider registers or vector instructions.

target-cpu=native makes plain old Rust code much more powerful. We don't need to write simd intrinsics, simd types, we can write one version of the code that works everywhere but the compiler can compile it well. It's not perfect, not always a replacement for hand implemented vectorization, but it's pretty good.

As of this writing, matrixmultiply is in plain rust. It should compile with any settings, but using -C target-cpu=native is a big benefit (more than 50% increase in throughput if you have avx). It would therefore be great if projects using it had an easy way to just flip the switch that they want the compiler to use all available cpu features.

@bluss
Copy link
Member Author

bluss commented Mar 31, 2016

Re #2112 (comment) this falls between the two scenarios in the comment. Neither testing nor required, just a very good thing to use when it's available.

@alexcrichton
Copy link
Member

Yeah I don't think we've quite figured out a great way to deal with these sorts of options today. There's RUSTFLAGS which can suffice in the meantime, but it's not a great interface unfortunately.

To me this is essentially the same question of exposing target-feature in Cargo to crates somehow. Ideally, though, the entire DAG is compiled with the same options (including the standard library) which is the hard part.

@retep998
Copy link
Member

I'd really like if I could set this to be the default for all my builds locally since I typically don't care about distributing binaries.

@bluss
Copy link
Member Author

bluss commented Apr 11, 2016

@retep998 That seems to be possible using build.rustflags in the user-wide cargo config.

@carols10cents carols10cents added A-profiles Area: profiles C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` labels Sep 25, 2017
@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-profiles Area: profiles C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

5 participants