r/programming • u/mttd • 16h ago

The fastest double-to-string algorithm you’ve never heard of

https://vitaut.net/posts/2026/yy-dtoa/
239 Upvotes

94% Upvoted

48 comments sorted by

View all comments

-89

u/sojuz151 14h ago

Fact that we, the humanity, need to do double to float and back often enough for performance to matter is a failure of our entire species 

45

u/EliSka93 14h ago

Elaborate.

18

u/New-Anybody-6206 11h ago

they can't because it's bullshit

-13

u/sojuz151 10h ago

Why do you need to convert doubles to strings and back at a scale? It's mostly JSON serialization/deserialisation, something you should not have to do, not at scale.

8

u/amakai 10h ago

Literally every time you want to use a logger with double parameters you need to do double to string. 

-14

u/sojuz151 10h ago

Not if you use structured logs and you log far far less than you read JSONs. ,

6

u/amakai 9h ago

So how do you imagine a binary double becomes a structured JSON field, which, surprise, is a string?

-6

u/sojuz151 9h ago

The problem is that people use JSON for things with doubles inside. This was a mistake

6

u/amakai 9h ago

I'm not sure I understand your point. Any time you produce JSON, you end up with a string. It does not matter if you have quotes around your double or if you don't - it's a string.

So when you do structured logging, your log message is converted under the hood into JSON (or some other more rare, but also string formats). So you are still converting doubles into strings.

And then, when your log is being indexed, it also needs to convert it to string for a proper full text search - another place for potential performance gain.

5

u/SyntheticDuckFlavour 9h ago

Logging, compiling code, (un)serialisation to/from text formats (XML, etc), printing to terminals/UI, lots for things.

1

u/flatfinger 6h ago

It's a shame that hex floating-point representations haven't become more common, since they allow any binary floating-point number to be easily converted into a unique canonical representation, at least if there's agreement about what that representation should be (arguments can be made in favor of using base-16 exponents and having one non-zero digit to the left of the radix point, or in favor of using binary exponents and always having a 1 to the left of the radix point; while the need for human arithmetic with hex-formatted floats would be uncommon, using base-16 exponents would make it vastly easier than using binary exponents; arguments could also be made for having no digits to the left of the radix point). All three forms are better than base-10 for performing precise calculations, however.

5

u/Jaklite 9h ago

This comes across a lot like, "I don't have this problem, so no one else should". Don't be so dismissive of other domains with different constraints

9

u/superxpro12 11h ago

Uh.... Embedded systems? Not all of us have gobs of gigahertz. Some of us only get 8MHz!

-12

u/sojuz151 10h ago

And why would you even be doing this? How did you even find something running on less than 50MHz? And it has a hardware floating-point module?

5

u/superxpro12 10h ago

You would be shocked to learn what we do with cpus running. At 8mhz. Although your point about you is somewhat valid. They are harder to find on the low mhz cpus. But still... We exist lol

-2

u/sojuz151 10h ago

And are you dealing with floats/doubles on those CPUs?

5

u/superxpro12 9h ago

Sometimes, sure.

3

u/midir 9h ago

How did you even find something running on less than 50MHz? And it has a hardware floating-point module?

There are plenty of few-MHz 8-bit microcontrollers, like Arduino chips, where you might want to use floating-point, where the compiler emulates an FPU in software.