"sqr is a place where one might be tempted to use a macro in C, but writing such a macro in a way that x doesn't get evaluated twice is tricky."

Slightly off-topic, but it's important to point out that in modern C, implementing such a function as a macro is always a mistake. You'd do it as an inline function.

Macros in modern C should only be used for code generation (for DRY). If the language supports doing it without a macro, then do it without a macro.

One of the main quality-of-life improvement of Rust over C and C++ IMO is the crate system, and how you don't have to worry about codes from other files not being inlined properly (there's LTO now but it's always more limited than compile-time inlining and optimization).

No need to move things to headers (no headers at all, actually), worry about forward declarations and exposing internal bits of the API etc... Just write the code normally and naturally and let the compiler figure it out. No need to consider subtle performance tradeoffs when deciding where to write the code, just put it where it makes sense.

My prof in Introduction to Programming always said: "Generally, it's a good idea to avoid decisions."

Page isn't loading for me, so here's a snapshot: https://archive.is/i5uvl

Clang also does some crazy-good SIMD optimizations if you set -march=native. But I think the Rust compiler is based on LLVM as well, right?

I'm not a Rust guy, so can someone explain to me why SIMD intrinsics are "unsafe"? They don't seem unsafe in the way that, I dunno, raw memory accesses are unsafe.

Non-portable, of course, I get.

For your `sqr` function, what is the benefit of writing `x * x` over using `x.powi(2)` [0]? You didn't mention it in the article, but did you find a performance improvement from doing this?

[0]: https://doc.rust-lang.org/std/primitive.f64.html#method.powi