Fastfloat – C++ library 4x faster than strtod | Hacker News Reader

Fastfloat – C++ library 4x faster than strtod

github.com

109 pointsdilawar17 comments

"faster than strtod" is hardly even worth mentioning. As the paper points out, if that's what you wanted there were already several libraries far faster than that. What's cool is it's also much faster than absl::from_chars, which had been the fastest thing around.

The implementation buried inside RapidJSON[0] is also very fast. Pretty much any library for protocols that encode floats to decimal strings needs such an implementation to be performance competitive.

Interestingly RapidJSON is one of the few JSON libraries for C++ that has a "full precision" mode. Most don't even do str->double conversions precisely.

[0] https://github.com/Tencent/rapidjson/blob/master/include/rap...

Why is strtod so slow. Lots of special cases? Or hard to change since hidden away.

strtod handles decimal and hexadecimal strings, trailing junk, whatever else the locale allows, etc. It's pretty branchy when you think about it.

I love the fact that it uses character ranges instead of NULL terminated strings so there is finally a string to float library where we can use std::string_view without going via std::string. Sure, there is supposedly std::from_chars _but_ it only has support for floats on the very newest versions of GCC (and Clang and VC++).

Discussed in https://news.ycombinator.com/item?id=25967482

Alternative question: I am looking for the fastest online unknown size integer parser possible in C/C++.

The best I have heard is Boost::Spirit [0].

[0]: https://kholdstare.github.io/technical/2020/05/26/faster-int...

Spirit supports parsing integers the same way Emacs supports editing commit messages, if that's all you need it doesn't pull its weight.

I recently was profiling some type -> string conversion methods in C++. It's surprising how much the locale stuff affects performance.

boost::lexical_cast is twice as fast for int -> string if the BOOST_LEXICAL_CAST_ASSUME_C_LOCALE macro is defined. The binary was also 55Kb smaller.

But Rapidjson's algo was faster still.

I wrote something similar many years ago. Strtod has to check for null on every byte, and doesn't get inlined

> Strtod has to check for null on every byte

https://lemire.me/blog/2020/09/03/sentinels-can-be-faster/

Seems like a corner case, no?

It depends heavily on context. I don't think the benefit of sentinels are only rarely encountered; not in my experience. But if you start out with the assumption that sentinels are always worse than pointer+size tuples, either for performance or ergonomics, then you're less likely to conceive of or recognize solutions where sentinels are better.

I tend to agree that occasions when sentinels are the better option are firmly in the minority. Although I'm a little uneasy saying that because it assumes we can construct a singular, meaningful solution space and enumerate occasions where one approach is preferable than the other. IME that's not a very profitable way to approach things. (I want to make a comment about the problematic, fuzzy concept of "string" in computer science and the dynamic of how people conceive of problem and solution spaces in various languages and domains, but that's a rabbit hole I won't be able to climb out of.)

as a rust dev, much appreciated that there is a rust port of this!

This is great. Someone had to do it. Thanks.

strtod is not a good benchmark. Is it faster than std::format or https://github.com/fmtlib/fmt?

That comparison makes no sense: fast_float parses floats whereas std::format and fmtlib print floats — they don't do the same thing.

Reply on news.ycombinator.com