I'm guessing that f32::clone showing up in the profile isn't actually a call to f32::clone, because you have optimizations on (if it actually is a call to a "movd xmm0,dword ptr [rdi]; ret" instruction pair, that's a bug in the compiler). Rather it's the result of the compiler choosing to attribute seemingly-random lines to f32::clone, because when lines from multiple functions are fused into one instruction the compiler will just pick one, and it happened to pick f32::clone to write into the debug info. You really want to look at instruction-level profiling when you're profiling at that level instead of the individual functions, since debug info is going to be very unreliable.

I’m a Rust newbie, wondering how f32::clone could show up in a profile. Wouldn’t that be an inline no-op under any kind of optimization? I mean, cloning a float is, at worst, a MOV instruction, no?

That's really interesting -- I do enjoy a good optimisation.

I was looking at one of the diffs, and thinking at a sufficiently advanced compiler should be able to generate the same efficient code for both -- and indeed it does, if you turn the optimiser on: https://godbolt.org/z/hjP5qjabz

  - let shift = if (i / 32) % 2 == 0 { 32 } else { 0 };
  + let shift = ((i >> 5) & 1) << 5;

    let shift = ((~(i >> 5) & 1) << 5);

Great writeup with easy to understand steps. One thing it's lacking though is in the conclusion. I'd like to see a comparison to the C++ implementation.

I don't understand why half of these aren't optimized by the compiler automatically. (x - y).norm_squared()? Why is f32::clone() not just an inline mov? Begging a lot of questions.

> embedded Rust (lots of FFI & unsafe)

How much? And did the parts in safe Rust make up/protect the unsafe parts?

I’d be concerned that the reason there are fewer errors is because of the experience the team already had with the existing system. Porting or rewriting it would allow them to avoid many of the errors that were already fixed in the C implementation and errors they knew about ahead of time… assuming there’s more unsafe/FFI than safe.

Interesting read. How much speedup did you get in total? Steps of improvements don't always add up directly.

The fact that C++ does not force one to use/learn SIMD is a big advantage for C++ (not a fan of C++, but a fan of D).

What I would like to know personally is how complex is each code base.

Complex is nebulous so some metrics like

line counts or other code quality metrics would help.

  - let shift = if (i / 32) % 2 == 0 { 32 } else { 0 };
  + let shift = ((i >> 5) & 1) << 5;

Uh, that’s just `let shift = i & 32;`, right? Much easier to read, too, in my opinion.

(Edit: fixed from i % 32 to i & 32.)