Zmij: Faster floating point double-to-string conversion

(vitaut.net)

76 points | by fanf2 3 days ago ago

7 comments

  • floitsch 3 hours ago

    Pretty 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 2 hours ago

      Thank you! It means a lot coming from you, Grisu was the first algorithm that I implemented =). (I am the author of the blog post.)

  • mulle_nat 31 minutes ago

    Thank you for the code. I could port this easily to C and it solved a lot of portability issues for me.

  • andrepd 2 hours ago

    Very 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 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 2 hours ago

      I 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 41 minutes ago

        Indeed! 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.

  • Cold_Miserable an hour ago

    Already 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