--- title: Rust 1.98: Algebraic Float Methods and Release Candidate... description: Rust 1.98's release candidate is available, with stable release scheduled for August 20, installable early via rustup's dev-static distribution server. The... canonical: https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Rust 1.98: Algebraic Float Methods and Release Candidate Testing | daily.dev og:description: Rust 1.98's release candidate is available, with stable release scheduled for August 20, installable early via rustup's dev-static distribution server. The... og:url: https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn og:image: https://api.daily.dev/og/posts/XLMHw4sYN.png og:image:alt: Rust 1.98: Algebraic Float Methods and Release Candidate Testing 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. # Rust 1.98: Algebraic Float Methods and Release Candidate Testing **[Collections](https://daily.dev/sources/collections)** · 2 min read · 15 upvotes · 0 comments ## Summary Rust 1.98's release candidate is available, with stable release scheduled for August 20, installable early via rustup's dev-static distribution server. The headline feature is new opt-in algebraic floating-point methods for f32 and f64 (add, sub, mul, div, rem) that let the compiler reorder operations and vectorize more aggressively, trading strict IEEE-754 determinism for speed, similar to GCC/Clang's -ffast-math. The change stems from a 2025 bug report showing Rust's dot product implementations running up to 8x slower than equivalent C++ on modern x86_64 due to inability to reorder float operations for vectorization. Because the methods are opt-in rather than a global flag, developers choose where to accept looser semantics, avoiding the pitfalls that have plagued blanket fast-math usage in C++. The release also adds buffered integer formatting and other smaller changes. ## Content Rust 1.98.0 is on track for an August 20 release, and the release candidate is already available if you want to kick the tires early. You can install it locally through rustup using the dev-static distribution server. If you run into problems, there's an internals feedback thread for issues with the release itself, and a separate GitHub issue specifically for feedback on the pre-release testing process. ## Algebraic floating-point methods The headline feature here is a set of new methods on f32 and f64: `algebraic_add`, `algebraic_sub`, `algebraic_mul`, `algebraic_div`, and `algebraic_rem`. These let the compiler treat floating-point math more like real-number math, which opens the door to reordering operations and vectorizing loops more aggressively. It's the same basic idea behind the `-ffast-math` flag in C and C++ compilers. The tradeoff is determinism, not safety. Results from these methods can vary depending on optimization choices the compiler makes, but you won't get undefined behavior. That's an important distinction from how `-ffast-math` sometimes behaves in other languages. This wasn't added on a whim. A 2025 issue found that Rust's dot product computations could run up to 8x slower than equivalent C++ code on modern x86_64 chips, simply because Rust wasn't reordering float operations for vectorization. If you're doing numerical work where a small amount of imprecision is an acceptable tradeoff for speed, these new methods are worth a look. ## Buffered integer formatting Integer types now have a `format_into` method for writing formatted output into a buffer without extra allocations. Benchmarks put its performance in the same range as the `itoa` crate, which has been the go-to solution for this kind of thing for years. Nice to see this land in std. ## Other changes worth knowing about - A documentation guarantee was stabilized that closes a subtle undefined-behavior gap between `ManuallyDrop` and `Box` (the actual fix shipped back in 1.96.0 — this just documents the guarantee). - New stabilized APIs include `str::substr_range`, `NumBuffer`, the `String::from_utf16le`/`from_utf16be` family, and some helper methods on `Atomic`. If numerical performance has been a pain point for you in Rust, the algebraic methods are probably the most consequential change in this release. Everything else is solid, unglamorous std improvement — the kind of thing you don't notice until you need it. ## Questions this post answers ### What do the new algebraic_add, algebraic_mul, and related methods do in Rust 1.98? They let the compiler treat floating-point math more like real-number math, permitting reordering of operations and more aggressive loop vectorization, similar to the -ffast-math flag in C and C++. The tradeoff is reduced determinism, not safety: results can vary based on optimization choices, but no undefined behavior occurs, unlike some -ffast-math behavior in other languages. They apply to f32 and f64. _developers optimizing numerical Rust code can track std changes like these on daily.dev._ ### Why was Rust's dot product performance slower than C++ before algebraic float methods were added? Rust's dot product computations could run up to 8x slower than equivalent C++ code on modern x86_64 chips because Rust was not reordering floating-point operations for vectorization the way C++ compilers with fast-math flags do. This gap, identified in a 2025 issue, motivated the addition of algebraic_add, algebraic_sub, algebraic_mul, algebraic_div, and algebraic_rem methods in Rust 1.98. _anyone chasing numerical performance parity with C++ can follow Rust release changes on daily.dev._ ### What does the new format_into method do for integer formatting in Rust 1.98? It writes formatted integer output directly into a buffer without extra allocations, landing in the standard library in Rust 1.98. Benchmarks put its performance in the same range as the itoa crate, which had been the standard third-party solution for allocation-free integer formatting for years. _developers weighing std versus crate dependencies for formatting can track these tradeoffs on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 15 comments across lobsters, hackernews (as of 2026-09-13). **TL;DR:** Discussion centers almost entirely on the new algebraic float methods, with technical debate about how associativity/commutativity enable optimization and interest in ergonomic ways to use them, alongside a brief note appreciating Rust's slower feature pace. **Sentiment:** 55% positive · 40% mixed · 5% skeptical **The case for** - Detailed explanations show algebraic operations enable not just SIMD but also instruction-level parallelism and latency reduction in scalar code. - Some see potential for a user-defined Algebraic wrapper or proc-macro approach to make the feature more ergonomic. - One commenter praises the smaller, more restrained scope of recent Rust releases. **The pushback** - A concern was raised that reassociation and fma fusion can break careful rounding-error control relied on by techniques like double-double arithmetic. - Scoped operator overloading for algebraic methods was discussed as desirable but was previously considered and rejected for a wrapper-type approach. **By community** - lobsters (positive): Deep technical thread exploring why and how algebraic float operations enable optimization, plus ideas for making them easier to use ergonomically. - hackernews (positive): Brief comment welcoming the trend of fewer new features per release. **Open questions** - Is there a good ergonomic way (scoped operator overloading, proc macros, or a wrapper type) to use algebraic methods without verbose method calls? - How much does reassociation/fma fusion from algebraic operations risk breaking precision-sensitive techniques like double-double arithmetic? **Highlights** > > 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. > — [pervognsen on lobsters · 1 points, 1 comments](https://lobste.rs/s/hbjeir/announcing_rust_1_98_0#c_dnmonr) > 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.) > — [gspr on lobsters · 1 points, 3 comments](https://lobste.rs/s/hbjeir/announcing_rust_1_98_0#c_s6h5n1) > Having read that recently, I was interested by yesterday’s article on [double-double](https://lobste.rs/s/mxnn9v/double_double_31_digits_precision) which warns that reassociation and fma fusion break the kind of careful control over rounding errors that double-double relies on. > — [fanf on lobsters · 1 points](https://lobste.rs/s/hbjeir/announcing_rust_1_98_0#c_hgyein) > this could have been solved with making an `Algebraic` wrapper for integers, as was done with `Wrapping`. this was [considered and rejected](https://github.com/rust-lang/libs-team/issues/532#issuecomment-2630439118), although it could be done in a user library. > — [goldstein on lobsters · 4 points](https://lobste.rs/s/hbjeir/announcing_rust_1_98_0#c_rpvz07) > I really like we are getting less new features on each release overtime. It feels that language is currently in a sweet spot that should be protected from new features creep! > — [ammarabouzor on hackernews](https://news.ycombinator.com/item?id=49379814) **Source threads** - [lobsters](https://lobste.rs/s/hbjeir/announcing_rust_1_98_0) · 33 points · 13 comments - [hackernews](https://news.ycombinator.com/item?id=49378813) · 17 points · 2 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 - [Faster floating point math with Rust’s new API](https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9) · Lobsters · 0 upvotes · 0 comments --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#performance](https://daily.dev/tags/performance), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn) ```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":"Rust 1.98: Algebraic Float Methods and Release Candidate Testing","url":"https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn"},"datePublished":"2026-08-20T17:39:49.140Z","dateModified":"2026-09-13T19:49:17.101Z","description":"Rust 1.98's release candidate is available, with stable release scheduled for August 20, installable early via rustup's dev-static distribution server. The...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2787e9cf9013eba8a561b0e3e0df424b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2787e9cf9013eba8a561b0e3e0df424b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","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":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":15},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"general-programming,performance,rust","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"Rust 1.98: Algebraic Float Methods and Release Candidate Testing"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rust-1-98-algebraic-float-methods-and-release-candidate-testing-xlmhw4syn#faq","mainEntity":[{"@type":"Question","name":"What do the new algebraic_add, algebraic_mul, and related methods do in Rust 1.98?","acceptedAnswer":{"@type":"Answer","text":"They let the compiler treat floating-point math more like real-number math, permitting reordering of operations and more aggressive loop vectorization, similar to the -ffast-math flag in C and C++. The tradeoff is reduced determinism, not safety: results can vary based on optimization choices, but no undefined behavior occurs, unlike some -ffast-math behavior in other languages. They apply to f32 and f64. developers optimizing numerical Rust code can track std changes like these on daily.dev."}},{"@type":"Question","name":"Why was Rust's dot product performance slower than C++ before algebraic float methods were added?","acceptedAnswer":{"@type":"Answer","text":"Rust's dot product computations could run up to 8x slower than equivalent C++ code on modern x86_64 chips because Rust was not reordering floating-point operations for vectorization the way C++ compilers with fast-math flags do. This gap, identified in a 2025 issue, motivated the addition of algebraic_add, algebraic_sub, algebraic_mul, algebraic_div, and algebraic_rem methods in Rust 1.98. anyone chasing numerical performance parity with C++ can follow Rust release changes on daily.dev."}},{"@type":"Question","name":"What does the new format_into method do for integer formatting in Rust 1.98?","acceptedAnswer":{"@type":"Answer","text":"It writes formatted integer output directly into a buffer without extra allocations, landing in the standard library in Rust 1.98. Benchmarks put its performance in the same range as the itoa crate, which had been the standard third-party solution for allocation-free integer formatting for years. developers weighing std versus crate dependencies for formatting can track these tradeoffs on daily.dev."}}]} ```