Announcing Rust 1.98.0

There was an article a couple of weeks ago about these same operations and it had an example where adopting the algebraic operations allowed for SIMD optimization.

I'm trying to think of an example where reordering floating point operations would allow you to use something like SIMD where you couldn't before.

This isn't just for vectorization. A fundamental throughput optimization (whether done manually or automatically) is to restructure dataflow graphs to reduce or eliminate latency bottlenecks. As an example, you can replace ((a + b) + c) + d with (a + b) + (c + d) if addition is associative (or you treat it as associative as with Rust's algebraic_add).

When applied to loops (where it really matters) and optimizing for instruction-level parallelism, you usually also exploit commutativity, so you'd compute (a + c) + (b + d) rather than (a + b) + (c + d). Commutativity is also important for efficiently vectorizing a summation loop since you otherwise waste time in the inner loop on shuffles or horizontal adds. But the fundamental enabler for parallelism is associativity, not commutativity. [1]

Just to drive home the point about how this can be relevant for purely scalar code. An fadd execution unit is usually fully pipelined (each unit can sustain 1 fadd per cycle) while fadd latency is usually 2-4 cycles depending on the chip. Let's take a slightly older but representative micro-architecture like Skylake with 4-cycle fadd (addps) latency and 2 fadd ports. Then a left-chaining fadd loop with n additions (with n large enough to enter a steady state) will take ~4n cycles. That is 8x slower than the scalar throughput limit (8x rather than 4x since there are 2 ports).

[1] Incidentally, IEEE 754 addition is commutative outside of corner cases like adding two NaNs where the NaN bit patterns are different, which isn't relevant here.

Also see https://doc.rust-lang.org/beta/core/primitive.f32.html#algebraic-operators for slightly improved docs that unfortunately didn't make it into this release.

Does anyone know if something like scoped replacement of infix operators has been considered? It would be notationally nice to be able to say that within a certain scope, any occurrence of + means algebraic_add (or saturating_add or whatever other special variant). Especially these new algebraic math functions are likely to occur in quite long and complicated expressions that would end up a lot more readable if the operators could be temporarily overloaded.

I'm imagining something like

fn foo(x: f64, y: f64) -> f64 {
    let z = {
        #![infix_replace(+, algebraic_add)]

       x+y // Actually x.algebraic_add(y). Imagine a long and complicated expression here.
    };
   z+x+y // Normal addition 
}

More likely, you'd have an AlgebraicAdd trait that mirrors Add, and an attribute like #![add_replace(AlgebraicAdd)] for each of the infix operators.

It would also let you turn on things like explicit checked arithmetic (in every compilation mode) for certain specified functions/scopes without getting very verbose.

(I know operator overloading is a contentious topic. While I'm personally a huge fan of freely overloadable/extensible infix operators à la Haskell, I do understand why Rust isn't considering that. A limited, scoped variant might still be worth discussing though.)