ryu VS dragonbox

You can report the problems at https://github.com/faucetsdn/ryu/issues

Apparently exact minimal float-to-string conversion is more recent than I thought, and many languages used to print more (Python?) or less (PHP) decimal digits than necessary to uniquely identify the bit pattern. Python correctly prints 46000.80 + 553.04 as 46553.840000000004, but I don't know if it ever prints more digits than needed. One recent algorithm for printing floats exactly is https://github.com/ulfjack/ryu, though I'm unaware what's the state-of-the-art (https://github.com/jk-jeon/dragonbox claims to be a benchmark and the best algorithm).

A recent update to fmt was posted to r/cpp 3 days ago (https://www.reddit.com/r/cpp/comments/vrxkt0/fmt_90_released_with_improvements_to_floating/), and since that's still fresh on people's minds, they'll wonder how yours compares; and they'll probably wonder how it compares in terms of precision, round trip-ability, and performance of DragonBox https://github.com/jk-jeon/dragonbox. By "they", I probably mean "me" :D.

Existing fast and correct float-to-string implementations are out there. Just use them: https://github.com/jk-jeon/dragonbox. Or maybe use your stdlib if it has good support

Parse floats faster with dragonbox

Even if what you say is true, it makes little sense to not reuse it. There are other concerns here and one of them is code size. But to address the performance issue, fmtlib is doing under 50ns for most fp numbers via dragonbox(https://github.com/jk-jeon/dragonbox has the chart). So still cpu bound, but all FP output is CPU bound. At this point, what prices are we trading for faster?

There are some benchmarks in https://github.com/jk-jeon/dragonbox#performance. TL;DR it's faster than other state of the art algorithms like Ryu, Schubfach and variations of Grisu. We saw a nice speed up when switching from Grisu3 to Dragonbox in {fmt}: https://github.com/fmtlib/fmt/pull/1882 and it has been improved even more since then.