6 ms·
Zmij: Faster floating point double-to-string conversion
- floitsch 10mo agoPretty impressive. When I published Grisu (Google double-conversion), it was multiple times faster than the existing algorithms. I knew that there was still room for improvement, but I was at most expecting a factor 2 or so. Six times faster is really impressive.
- vitaut 10mo agoThank you! It means a lot coming from you, Grisu was the first algorithm that I implemented =). (I am the author of the blog post.)
- andrepd 10mo agoVery interesting! I wonder how Teju Jaguá compares. I don't see it in the C++ benchmark repo you linked and whose graph you included. I have contributed an implementation in Rust :) https://crates.io/crates/teju https://crates.io/crates/teju it includes benchmarks which compare it vs Ryu and vs Rust's stdlib, and the readme shows a graph with some test cases. It's quite easy to run if you're interested!
- vitaut 10mo agoI am not sure how it compares but I did use one idea from Cassio's talk on Teju: > A more interesting improvement comes from a talk by Cassio Neri Fast Conversion From Floating Point Numbers. In Schubfach, we look at four candidate numbers. The first two, of which at most one is in the rounding interval, correspond to a larger decimal exponent. The other two, of which at least one is in the rounding interval, correspond to the smaller exponent. Cassio’s insight is that we can directly construct a single candidate from the upper bound in the first case.
- andrepd 10mo agoIndeed! I saw that you linked to Neri's work, so you were aware of Teju Jaguá. I might make a pull request to add it to the benchmark repo when I have some time :) Another nice thing about your post is mentioning the "shell" of the algorithm, that is, actually translating the decimal significand and exponent into a string (as opposed to the "core", turning f * 2^e into f' * 10^e'). A decent chunk of the overall time is spent there, so it's worth optimising it as well.
- vlovich123 10mo agoAny ideas why Rust’s stdlib hasn’t adopted faster implementations?
- Cold_Miserable 10mo agoAlready done ages ago. Nothing more of interest. The bottleneck are the 3 conditionals: - positive or negative - positive or negative exponent, x > 10.0 - correction for 1.xxxxx * 2^Y => fract(log10(2^Y)) 1.xxxxxxxx > 10.0
- mulle_nat 10mo agoThank you for the code. I could port this easily to C and it solved a lot of portability issues for me.
- vitaut 10mo agoI've added a C implementation in https://github.com/vitaut/zmij/blob/main/zmij.c https://github.com/vitaut/zmij/blob/main/zmij.c in case you are interested.
- mulle_nat 10mo agoNice, but it's too late I needed a different API for future use in my custom sprintf so I made mulle-dtostr (https://github.com/mulle-core/mulle-dtostr https://github.com/mulle-core/mulle-dtostr). On my machine (AMD) that benchmarked in a quick try quite a bit faster even, but I was just checking that it didn't regress too badly and didn't look at it closer.
- vitaut 10mo agoPlease note that there is some error in your port: Error: roundtrip fail 4.9406564584124654e-324 -> '5.e-309' -> 4.9999999999999995e-309 Error: roundtrip fail 6.6302941479442929e-310 -> '6.6302941479443e-309' -> 6.6302941479442979e-309 Error: roundtrip fail -1.9153028533493997e-310 -> '-1.9153028533494e-309' -> -1.9153028533493997e-309 Error: roundtrip fail -2.5783653320086361e-312 -> '-2.57836533201e-309' -> -2.5783653320099997e-309
- NovemberWhiskey 10mo agoWhen I saw the title here, my first thought was “wow, these RISC-V ISA extensions are getting out of hand”
- HexDecOctBin 10mo agoIt seems that most research effort goes into better dtoa, and not enough in a better atod. There are probably a dozen dtoa algorithms now, and (I think?) two for atod. Anyone know why?
- vitaut 10mo agoGood question. I am not familiar with string-to-double algorithms but maybe it's an easier problem? double-to-string is relatively complex, people even doing PhD in this area. There is also some inherent asymmetry: formatting is more common than parsing.
- mdf 10mo ago> formatting is more common than parsing. Is it, though? It's genuinely hard for me to tell. There's both serialization and deserialization of data sets with, e.g., JSON including floating point numbers, implying formatting and parsing, respectively. Source code (including unit tests etc.) with hard-coded floating point values is compiled, linted, automatically formatted again and again, implying lots of parsing. Code I usually work with ingests a lot of floating point numbers, but whatever is calculated is seldom displayed as formatted strings and more often gets plotted on graphs.
- adrian_b 10mo agoFor serialization and deserialization, when the goal is to produce strings that will be read again by a computer, I consider the use of decimal numbers as a serious mistake. The conversion to string should produce a hexadecimal floating-point number (e.g. with the "a" or "A" printf conversion specifier of recent C library implementations), not a decimal number, so that both serialization and deserialization are trivial and they cannot introduce any errors. Even if a human inspects the strings produced in this way, comparing numbers to see which is greater or less and examining the order of magnitude can be done as easy as with decimal numbers. Nobody will want to do exact arithmetic computations mentally with such numbers.
- vitaut 10mo ago
- amluto 10mo agoI read the post and the companion post: https://vitaut.net/posts/2025/smallest-dtoa/ https://vitaut.net/posts/2025/smallest-dtoa/ And there’s one detail I found confusing. Suppose I go through the steps to find the rounding interval and determine that k=-3, so there is at most one integer multiple of 10^-3 in the interval (and at least one multiple of 10^-4). For the sake of argument, let’s say that -3 worked: m·10^-3 is in the interval. Then, if m is not a multiple of 10, I believe that m·10^-3 is the right answer. But what if m is a multiple of 10? Then the result will be exactly equal, numerically, to the correct answer, but it will have trailing zeros. So maybe I get 7.460 instead of 7.46 (I made up this number and I have no idea whether any double exists gives this output.) Even though that 6 is definitely necessary (there is no numerically different value with decimal exponent greater than -3 that rounds correctly), I still want my formatter library to give me the shortest decimal representation of the result. Is this impossible for some reason? Is there logic hiding in the write function to simplify the answer? Am I missing something?
- vitaut 10mo agoThis is possible and the trailing zeros are indeed removed (with the exponent adjusted accordingly) in the write function. The post mentions removing trailing zeros without going into details but it's a pretty interesting topic and was recently changed to use lzcnt/bsr instead of a lookup table.
- nhatcher 10mo agoThis blows my mind TBH. I used to say a few years back that Ryu is my favorite modern algorithm but it felt so complicated. Your C implentation almost feels... simple! Congratulations, can't wait to have some time to study this further
- vitaut 10mo agoThank you! The simplicity is mostly thanks to Schubfach although I did simplify it a bit more. Unfortunately the paper makes it appear somewhat complex because of all the talk about generic bases and Java workarounds.
- adgjlsfhk1 10mo agoI've just started a Julia port and I think it will be even cleaner than the C version (mostly because Julia gives you a first class (U)Int128 and count leading zeros (and also better compile time programming that lets you skip on writing the first table out explicitly).
- nhatcher 10mo agoOh wow, I would love to see that if you can share it :)
- adgjlsfhk1 10mo agoOnce I finish it, I'll be PRing to the Julia repo (to replace the current Ryu version), and I'll drop a link here.
- vitaut 10mo agoI started a section to list implementations in other languages: https://github.com/vitaut/zmij?tab=readme-ov-file#other-languages https://github.com/vitaut/zmij?tab=readme-ov-file#other-lang.... Once yours is complete feel free to submit a PR to add it there.
- Scaevolus 10mo agoIs the large significands table (~19KB) an issue for cache contention in practical use, or are only a small range of significands generally accessed?
- vitaut 10mo agoIt depends on the input distribution, specifically exponents. It is also possible to compress the table at the cost of additional computation using the method from Dragonbox.