What does HackerNews think of fast_float?

Fast and exact implementation of the C++ from_chars functions for float and double types: 4x faster than strtod

Language: C++

#4 in C++
#2 in C++
#72 in Linux
#50 in macOS
This makes sense for integers but beware floating point from_chars - libc++ still doesn't implement it and libstdc++ implements it by wrapping locale-dependent libc functions which involves temporarily changing the thread locale and possibly memory allocation to make the passed string 0-terminated. IMO libstdc++'s checkbox "solution" is worse than not implementing it at all - user's are better off using Lemire's API-compatible fast_float implementation [0].

Of course it's possible that the author wanted to support compilers released before 2018 when that code was written in which case not even integer from_chars would be available.

[0] https://github.com/fastfloat/fast_float

OTOH MXCSR being threadlocal means that automatically linking crtfastmath.o makes even less sense as it only affects the inital thread that loaded the object so you still need to set FTY/DAZ manually if you really want them.

And implicit locales should just die. It's sad that even newer functionality like std::format relies on them. Sadder that if it didn't then you'd probably have compiler developers pulling shit like GCC/libstdc++ does for std::from_chars [0] which defeats the entire point of that function but hey, at least they can mark that as implemented. Not like there are suitably licensed implementations of the functionality [1] available that they could use instead if they don't want to implement float parsing themselves.

[0] https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/s...

[1] https://github.com/fastfloat/fast_float

Any body wanting to port the fast float parser in java too ? https://github.com/fastfloat/fast_float

Lemire's really has made a huge contribution to computer science

Some fun things I've figured out:

* https://github.com/fastfloat/fast_float <-- for fast float/double conversion

* from_chars() for fast integer conversion (though I benchmarked a few that were slightly faster but probably less robust), see https://en.cppreference.com/w/cpp/utility/from_chars

* https://github.com/simdjson/simdjson <-- apparently the fastest JSON library

It's hard to program normal anymore, for every little thing I ask myself "but I want it faster!" TypeScript was so much easier, other than O(n) and friends, I never cared xD

Here's a more recent blog post: [1] and a published paper on arxiv: [2], describing the latest version of the algorithm which is implemented in fast_float C++ library [3].

Coincidentally, I've participated in this as well recently by implementing the algorithm in Rust (fast-float crate, see [4] for the source and benchmarks). It is insanely fast (easily over 1GB/s on an m1 machine) and beats all of the existing float parsers I'm aware of by a large margin, at least on the datasets we've tested it on.

[1] https://lemire.me/blog/2021/01/29/number-parsing-at-a-gigaby...

[2] https://arxiv.org/pdf/2101.11408.pdf

[3] https://github.com/fastfloat/fast_float

[4] https://github.com/aldanor/fast-float-rust/

He touched on JSON parsers in a previous post about fast_double_parser: "People who write fast parsers tend to roll their own number parsers (e.g., RapidJSON, sajson), and so we did. However, we sacrifice some standard compliance." (The "we" in this context refers to simdjson.)

https://lemire.me/blog/2020/03/10/fast-float-parsing-in-prac...

He followed up in a comment: "RapidJSON has at least two fast-parsing mode. The fast mode, which I think is what you refer to, is indeed quite fast, but it can be off by one ULP, so it is not standard compliant."

The Github README for this new project says, "The fast_float library provides a performance similar to that of the fast_double_parser library."

https://github.com/fastfloat/fast_float

However, the benchmarks show a significant improvement relative to those in the fast_double_parser README:

https://github.com/lemire/fast_double_parser

I tried to run the benchmarks, but my CMake is apparently too old, and Homebrew barfed all over the living room rug when I tried to update it.