--- title: Faster floating point math with Rust’s new API | daily.dev description: Rust 1.98 introduces algebraic floating-point operators that let developers explicitly tell the compiler when it can reorder or otherwise optimize... canonical: https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Faster floating point math with Rust’s new API | daily.dev og:description: Rust 1.98 introduces algebraic floating-point operators that let developers explicitly tell the compiler when it can reorder or otherwise optimize... og:url: https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9 og:image: https://api.daily.dev/og/posts/ZYoeD6FM9.png og:image:alt: Faster floating point math with Rust’s new API og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Faster floating point math with Rust’s new API **[Lobsters](https://daily.dev/sources/lobsters)** · 10 min read · 0 upvotes · 0 comments ## Summary Rust 1.98 introduces algebraic floating-point operators that let developers explicitly tell the compiler when it can reorder or otherwise optimize floating-point operations. By default, compilers treat floating-point math conservatively because addition is not associative, preventing SIMD vectorization. The new `.algebraic_add()`, `.algebraic_sub()`, and `.algebraic_mul()` methods signal that reordering is acceptable in specific code sections. A pairwise summation implementation using these operators outperforms both a naive float sum and NumPy's implementation while maintaining comparable numerical accuracy. A sum-of-squared-differences example shows a 1.7x speedup. The key insight is mixing strict operators (for accuracy-critical parts) with algebraic operators (for speed-critical inner loops). ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 11 comments across lobsters (as of 2026-08-03). **TL;DR:** The community is broadly positive about Rust's algebraic floating-point operations, appreciating their granularity and safety compared to -ffast-math, though one commenter raises nuanced questions about the operational semantics and potential for surprising behavior. **Sentiment:** 60% positive · 30% mixed · 10% skeptical **The case for** - Algebraic ops are per-operation rather than per-function/translation-unit, giving finer-grained control than -ffast-math. - Unlike -ffast-math, they avoid undefined behavior by default. - The article's explanation was praised as succinct and well-illustrated, including hardware perf counter statistics. **The pushback** - The operational semantics are unclear — it's uncertain whether results are deterministic within a single run or whether optimization passes could cause miscompilation in edge cases. - Code relying on algebraic ops alongside exact IEEE-754 comparisons may produce surprising or hard-to-reason-about results. **By community** - lobsters (positive): Discussion is largely constructive and positive, with technical clarifications about -ffast-math improvements in GCC 13/Clang 19 and one deeper concern about algebraic op semantics. **Hottest debate:** Whether algebraic floating-point operations have well-defined enough semantics to avoid subtle miscompilations when mixed with exact IEEE-754 comparisons. **Open questions** - Are the results of algebraic operations guaranteed to be fixed (non-varying) within a single program run, or are they truly non-deterministic like freeze poison in LLVM IR? - Do floats effectively have 'provenance' under algebraic ops, and do optimization passes account for this consistently? **Highlights** > The operational semantics of algebraic operations leave me confused, hopefully someone can explain it. The docs say: > Because of the unpredictable nature of compiler optimizations, the same inputs may produce different results even within a single program run. Unsafe code must not rely on any property of the return value for soundness. Surely there is at least a guarantee that the return value is at least fixed? I don't take it for granted because optimization passes may duplicate code, and algebraic operations are non-deterministic. Is their behavior close to `freeze poison`? I'm getting confused because `a.algebraic_add(b)` can produce different results depending on where `a` comes from, even if it has the same value (e.g. if it's a constant vs if it's multiplication, which could result in FMA). Does that imply that floats have provenance? It sure looks similar, and that raises a question about whether visibly equal values with different provenances are equivalent and whether optimisation passes take that into account, e.g. let sum = a + b; let algebraic = sum.algebraic_sub(b); let exact = sum - b; if algebraic == exact { // (1) assert_eq!(algebraic, a); // (2) } Individually, (1) could be reasonably optimized to `true` (assuming the algebraic difference is computed with IEEE-754 semantics, and no NaNs) and (2) could be reasonably optimized to `true` (assuming it's computed symbolically), but together they could result in a miscompilation. Last time I tried this, I couldn't get LLVM to miscompile this, but I don't know if that's for lack of trying or because this is deliberately taken into account in each pass -- and not a single discussion about Rust's algebraic arithmetic API I could find covers this. > — [purplesyringa on lobsters · 1 points, 1 comments](https://lobste.rs/s/jnznnu/faster_floating_point_math_with_rust_s_new#c_v6ewna) > Somewhat, yes, but better: 1. It doesn't have undefined behavior; fast-math by default turns on stuff that does. In practice you can choose to opt-in only to the optimizations that aren't going to be a problem that way, though. 2. It's per operation, whereas fast-math is (at best) per function. > — [itamarst on lobsters · 2 points, 1 comments](https://lobste.rs/s/jnznnu/faster_floating_point_math_with_rust_s_new#c_ra7lib) > > -ffast-math has global side-effects that harm the behaviour of code that is not compiled with -ffast-math, because is messes with the floating point environment As noted in the article [GCC 13 no longer does that (by default?)](https://gcc.gnu.org/gcc-13/changes.html): > `-Ofast`, `-ffast-math` and `-funsafe-math-optimizations` will no longer add startup code to alter the floating-point environment when producing a shared object with -shared. [Clang 19 made a similar change as well](https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html) ([corresponding GitHub PR](https://github.com/llvm/llvm-project/pull/80475)): > Shared libraries linked with either the `-ffast-math`, `-Ofast`, or `-funsafe-math-optimizations` flags will no longer enable flush-to-zero floating-point mode by default. This decision can be overridden with use of -mdaz-ftz. This behavior now matches GCC’s behavior. > — [aw1621107 on lobsters · 2 points, 1 comments](https://lobste.rs/s/jnznnu/faster_floating_point_math_with_rust_s_new#c_ytcuq3) > I was already familiar with the problem space and had glanced at Rust's algebraic ops before, but I really liked the explanation given here. It was succint and made its points really well! I also appreciate the statistics on how many SIMD operations occurred (which I assume were collected with hardware perf counters), it's a nice touch. > — [bal-e on lobsters · 1 points, 1 comments](https://lobste.rs/s/jnznnu/faster_floating_point_math_with_rust_s_new#c_8lgjpl) **Source threads** - [lobsters](https://lobste.rs/s/jnznnu/faster_floating_point_math_with_rust_s_new) · 25 points · 11 comments ## Similar posts on daily.dev - [Rust language adds algebraic floating-point methods](https://daily.dev/posts/rust-language-adds-algebraic-floating-point-methods-jimyxkos8) · InfoWorld · 1 upvotes · 0 comments - [Implementing FMA and finding bugs in C and Rust standard libraries](https://daily.dev/posts/implementing-fma-and-finding-bugs-in-c-and-rust-standard-libraries-kdjaxc6j0) · Lobsters · 0 upvotes · 1 comments - [Operators of death: checked arithmetic in Rust — Bitfield Consulting](https://daily.dev/posts/operators-of-death-checked-arithmetic-in-rust-bitfield-consulting-ruiyndmyn) · Bitfield Consulting · 5 upvotes · 0 comments - [SIMD programming in pure Rust](https://daily.dev/posts/simd-programming-in-pure-rust-idnkdlsse) · Hacker News · 2 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Faster floating point math with Rust’s new API","url":"https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9"},"datePublished":"2026-08-03T07:51:10.726Z","dateModified":"2026-08-03T13:22:02.234Z","description":"Rust 1.98 introduces algebraic floating-point operators that let developers explicitly tell the compiler when it can reorder or otherwise optimize...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/20b05036b1015cc4d4f638c2e538b5f5?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/20b05036b1015cc4d4f638c2e538b5f5?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"python,rust","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Faster floating point math with Rust’s new API"}]} ```