Maybe I'm missing something, but it looks like about a third of the functions in by_ref.cpp take their parameters by value:
https://www.forrestthewoods.com/blog/should-small-rust-struc...
Should small Rust structs be passed by-copy or by-borrow?
21–30 of 115 posts
Re: Should small Rust structs be passed by-copy or by-borrow?
#22For the difference between rust and C++ I'd say is caused by the difference between rustc+llvm and msvc++ compilers. Compiling C++ under clang should give more comparable results
I did find it frustrating that Clang wasn't the first thing he tried. But he did eventually try Clang past the end of the post (when it should've been at the top). Interestingly though, Clang doesn't bridge the gap.
> Interestingly though, Clang doesn't bridge the gap.
That might be due to differences in the code, but it might just as well be due to differences in the flags that rustc and Clang pass to the backend by default. It's not even clear what optimization level they asked for.
Re: Should small Rust structs be passed by-copy or by-borrow?
#23This purports to discuss pass-by-copy or reference but ends up not discussing that particular issue at all since every single compiler naturally inlined and vectorized his trivial micro-benchmark. If you were to discuss the headline issue, I guess you could delve deep into calling conventions, register pressure, various instruction set extensions that compilers can abuse to carry the data.. or you take the compiler o…
yeah, writing microbenchmarks (coming from java) is an art of its right own. It requires knowledge what can and could be optimized given the context.
Trying to guide compilers with hints is a futile effort and most of the time compilers would be expending best effort to begin with.
Re: Should small Rust structs be passed by-copy or by-borrow?
#24Will the Rust compiler convert one to the other as a performance optimisation where possible?
Yes - even if you ask for pass by move, it might pass a reference for a large struct.
Re: Should small Rust structs be passed by-copy or by-borrow?
#25A good rule is to let the caller decide. If input parameters are by-reference and the caller wants to make them by-reference, congrats, no problem. If caller wants the parameters to by a copy, they can create a clone and pass a reference. But if you impose the input parameters to by copy, there's no way back.
In the case of Rust it would typically be an immutable reference (or else passing by value wouldn't be an alternative). So the caller would have no reason to make a copy.
Re: Should small Rust structs be passed by-copy or by-borrow?
#26For the difference between rust and C++ I'd say is caused by the difference between rustc+llvm and msvc++ compilers. Compiling C++ under clang should give more comparable results
It's mentioned at the end of the article that clang doesn't make much of a difference.
Re: Should small Rust structs be passed by-copy or by-borrow?
#27A good rule is to let the caller decide. If input parameters are by-reference and the caller wants to make them by-reference, congrats, no problem. If caller wants the parameters to by a copy, they can create a clone and pass a reference. But if you impose the input parameters to by copy, there's no way back.
Although your point is sort-of true, but I don't really see how it's valid here. The author is talking about the performance implications of the two approaches in situations where the function parameters are not mutated. Suggesting that user "makes the choice" here by taking defensive copies for themselves will probably (but who knows what the optimisers will do - they might just elide it) make performance worse. It's not something end users will think to do, anyway, at least not in the name of performance.
Regardless, I want a library author to help me fall into the pit of performance success, not expect me to do it all for myself.
Re: Should small Rust structs be passed by-copy or by-borrow?
#28Will the Rust compiler convert one to the other as a performance optimisation where possible?
Yes - even if you ask for pass by move, it might pass a reference for a large struct.
That's interesting, and a bit surprising. I know Ada does this, but it's explicit about only specifying semantics ("in, "out" or "in out") and letting the compiler decide.
Surely C or C++ optimizers won't do this?
Re: Should small Rust structs be passed by-copy or by-borrow?
#29You should be careful trying to apply these micro benchmarks to modern optimising compiles, behaviour may be different depending on the exact code being compiled. Rust especially has immutability and known types in generics at compile time, so the compiler can do a lot of pointer and inlining magic that C and other languages can't. In the below example Rust switches to using a pointer when you might think it's doing…
> so the compiler can do a lot of pointer and inlining magic that C and other languages can't.
Isn't this a negative for Rust for when you actually do care about such micro-optimizations? It feels as if you not only need to know the language itself but also how the particular version of the compiler you are using has decided to interpret the language and apply optimizations - essentially having to know how the magic trick is performed.
AFAIK this is why Free Pascal added constref in addition to const (which existed since the 90s in Delphi) - the latter doesn't guarantee pass-by-reference (even if in most cases it will do that) so if you care about that you need to know how the compiler you are using will treat it (thus needing to know more than just the language) but constref does exactly that. Now granted this was mainly done for interfacing with external code written in other langauges than micro-optimizations, but it still applies that if you cared about what the compiler will produce you had to rely on "magic knowledge" before constref was introduced.
Re: Should small Rust structs be passed by-copy or by-borrow?
#30Interesting article. I enjoyed it. I have two thoughts. ==== 1. Regarding the benchmark itself, I wonder out loud if CPU caching could have a meaningful alter on the results. The article says : > I randomly generate 4000 spheres, capsules, segments, and triangles. It is not clear to me if this is enough to fill CPU L1 cache or not. My guess is that it is not. If all the benchmark indeed happens within the L1 cache, I…
the author doesn't make the data representation explicit, but if doubles are used for positions, 4000 triangles alone would be 288,000 bytes (8 bytes * 3 indices * 3 vecs * 4000). 4,000 of each would spill the largest L1 cache I know of on a mainstream processor (512 KB) and they would still be too big to fit in L1 cache of most modern CPUs even if the vectors used floats. it wouldn't be a huge margin though.
I agree with your point 2) in general. first try for the closest mapping between language semantics and program semantics. come back and do weird stuff later after profiling.