Thank you! Teju Jagua is a nice algorithmic improvement of Schubfach but unfortunately I don't have any numbers. I would expect it to be an improvement over Ryu both in terms of perf and simplicity but you could do even better with yy's approach (1 wide multiplication instead of 2-3): https://vitaut.net/posts/2026/yy-dtoa/.
Oh, you wrote a post explaining this algorithm. I'll probably have a deep look when I get some time. Thanks for writing it!
By the way, how dare you deliberately discard the lineage of boxed (schubfach-ed) dragons! Well, if you did so, Zmij would have looked like a variant of dragonbox when it's not so I guess it's maybe my fault of preoccupying that name combination😂
Actually I did find a comparison of Zmij and Teju although in Rust: https://github.com/dtolnay/dtoa-benchmark#results. Zmij was more than 2x faster at the time of comparison which is not very surprising knowing the algorithms.
Not yet, but those should be easy to add. The hardest is float128_t but all the functionality is already there because binary128 is already supported via long double on certain platforms.
Thanks for the reply. I think it would be great if Zmij provided those overloads.
One thing I found lacking in the std::to_chars API is the maximum buffer length required by a particular (floating-point) type. Having it as a constant IMO simplifies the code and enables more efficiency. This also applies when converting integers to chars. Are there any plans for supporting integral types? If so, Zmij would be a great drop-in replacement for std::to_chars going forward.
If somebody provides a suitable patch and shows benchmarks there's a very high chance, otherwise none at all. We already have patches and benchmarks for Teju Jagua and will go with that unless somebody does the work to show Zmij is better.
21
u/jwakely libstdc++ tamer, LWG chair 14d ago
Wonderful work. Have you compared it to Cassio Neri's Teju Jagua? That's what we're planning to use in GCC instead of Ryu.