7 ms·

I’d love to see how that compares to zmij: https://github.com/dtolnay/dtoa-benchmark https://github.com/dtolnay/dtoa-benchmark

e4m2 1mo ago
The upstream fmtlib dtoa-benchmark integrates uscale (https://fmtlib.github.io/dtoa-benchmark/results/ https://fmtlib.github.io/dtoa-benchmark/results/). It uses C code from Russ Cox's original fpfmt repository (https://github.com/rsc/fpfmt/tree/main/bench/uscalec https://github.com/rsc/fpfmt/tree/main/bench/uscalec), which is slightly different from the Go code upthread. Zmij and xjb are in a league of their own. Broadly speaking, dtoa first has to find the shortest decimal representation of the floating-point input, and then format that decimal representation into a string. Zmij and xjb pull far ahead of the others mostly by speeding up the second part of that process. uscale is quite good without the stringification, as are many other algorithms. I would say uscale's main strength isn't its speed, but rather its simplicity and, more importantly, the fact that it does both formatting and parsing using a single ~11 KiB table, which no other state-of-the-art algorithm offers (although yy comes close).
- vitaut 29d ago
  The core of newer methods like yy, xjb and zmij is remarkably simple: https://vitaut.net/posts/2026/yy-dtoa/ https://vitaut.net/posts/2026/yy-dtoa/. Shortest uscale is basically Schubfach or, rather, it's variant called Teju Jagua and has 2-3 wide multiplications compared to 1 for newer methods. The complexity is optional and comes from squeezing the last few nanoseconds =).
  - e4m2 29d ago
    Right, that's basically what I was trying to say (in so many words). I learned a lot from your dtoa blog posts and Zmij's implementation. Thank you! > has 2-3 wide multiplications compared to 1 for newer methods. As written, the `shortFloat()` function always calls `uscale()` two times, followed by an optional third call. Each `uscale()` does two wide multiplications (one full 64x64->128 and one 64x64->hi64, in case we want to make that distinction), so that works out to either 4 or 6 wide multiplications in total. I think `shortFloat()` could be rewritten to always do exactly 2 wide multiplications (both 64x64->128) at the cost of some more ALU operations. However, I don't see how that could be further reduced to only one wide multiplication. EDIT: Going back to look at Zmij's to_decimal, I just realized that it also doesn't do just one wide multiplication in the sense I originally meant, so what you're saying is likely correct in the first place. I overzealously used a different definition of "wide multiplication", which I probably should've realized, given the fact that my numbers are exactly double yours, but alas. My apologies.

e4m2 1mo ago

The upstream fmtlib dtoa-benchmark integrates uscale (https://fmtlib.github.io/dtoa-benchmark/results/ https://fmtlib.github.io/dtoa-benchmark/results/). It uses C code from Russ Cox's original fpfmt repository (https://github.com/rsc/fpfmt/tree/main/bench/uscalec https://github.com/rsc/fpfmt/tree/main/bench/uscalec), which is slightly different from the Go code upthread. Zmij and xjb are in a league of their own. Broadly speaking, dtoa first has to find the shortest decimal representation of the floating-point input, and then format that decimal representation into a string. Zmij and xjb pull far ahead of the others mostly by speeding up the second part of that process. uscale is quite good without the stringification, as are many other algorithms. I would say uscale's main strength isn't its speed, but rather its simplicity and, more importantly, the fact that it does both formatting and parsing using a single ~11 KiB table, which no other state-of-the-art algorithm offers (although yy comes close).

vitaut 29d ago
The core of newer methods like yy, xjb and zmij is remarkably simple: https://vitaut.net/posts/2026/yy-dtoa/ https://vitaut.net/posts/2026/yy-dtoa/. Shortest uscale is basically Schubfach or, rather, it's variant called Teju Jagua and has 2-3 wide multiplications compared to 1 for newer methods. The complexity is optional and comes from squeezing the last few nanoseconds =).
- e4m2 29d ago
  Right, that's basically what I was trying to say (in so many words). I learned a lot from your dtoa blog posts and Zmij's implementation. Thank you! > has 2-3 wide multiplications compared to 1 for newer methods. As written, the `shortFloat()` function always calls `uscale()` two times, followed by an optional third call. Each `uscale()` does two wide multiplications (one full 64x64->128 and one 64x64->hi64, in case we want to make that distinction), so that works out to either 4 or 6 wide multiplications in total. I think `shortFloat()` could be rewritten to always do exactly 2 wide multiplications (both 64x64->128) at the cost of some more ALU operations. However, I don't see how that could be further reduced to only one wide multiplication. EDIT: Going back to look at Zmij's to_decimal, I just realized that it also doesn't do just one wide multiplication in the sense I originally meant, so what you're saying is likely correct in the first place. I overzealously used a different definition of "wide multiplication", which I probably should've realized, given the fact that my numbers are exactly double yours, but alas. My apologies.