11–20 of 115 posts
AIUI it recommends by-copy for structs of at most 8 bytes because it thinks that's the appropriate limit for 32-bit targets, and they don't like the set of warnings issued to change too much for different targets.
Note that Rust's "clippy" linter has a `trivially_copy_pass_by_ref` lint which recommends changing by-reference to by-copy for sufficiently small structs, but presumably it's aiming to be conservative. AIUI it recommends by-copy for structs of at most 8 bytes because it thinks that's the appropriate limit for 32-bit targets, and they don't like the set of warnings issued to change too much for different targets.
You can cut down on a lot of that by implementing basic operations (Add, Mul, etc.) for both value and reference types.
impl Add for Vector3 { … }
impl Add for Vector3 { … }
impl Add for &Vector3 { … }
impl Add for &Vector3 { … }
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 wonder how a bigger workload would affect the results. Maybe it does not change anything. But maybe it does.
====
2. The author mentioned two criterion for choosing between by-copy and by-borrow : performance and ergonomics. I would add a third, somewhat related to ergonomics : let's call it semantics. When some piece of data naturally belongs somewhere and some others entities are natural "readers" of it, it might make sense to use the ownership / borrowing mechanism of Rust to naturally reflect this relationship, regardless of performance or code ergonomics.
In particular, a borrow guarantees you always work on a read-only, up to date value of the data. Meanwhile, after a pass by-copy the life cycles of the data seen by the caller and the data seen by the callee become independent of each other. This can have consequences, particularly in a multi-threaded environment.
This 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…
What was the third thing??
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...