Idea: adding Zmij for faster float-to-string parsing?

compiler
1

From these two sites: vitaut/zmij: A double-to-string conversion algorithm based on Schubfach and yy in C and C++ and dtolnay/zmij: Fast floating point to string conversion in pure Rust, they claim to be the fastest float-to-string parsing algorithm with the following features:

  • Round trip guarantee
  • Shortest decimal representation
  • Correct rounding
  • High performance
  • Small binary size
  • Fast compile time
  • IEEE 754 double and float support
  • Safer API than classic dtoa
  • User-friendly output format similar to Python's default representation
  • Zero dependencies
2

GitHub - dtolnay/zmij: Fast floating point to string conversion · GitHub seems to only have performance measurements, not binary size or cache usage measurements. Looking at zmij/src/lib.rs at master · dtolnay/zmij · GitHub I would be surprised if it compiled to compact code. And in real world use cases that do other things apart from parse floats, less icache and dcache usage often wins.

I would like to see the comprehensive measurements you base your statements above on, as well as benchmarks in real world usage (rather than just microbenchmarks). Also, benchmarks for something like this should be performed across a few different types of systems/architectures to make sure it is not a major regression on any, including at least one soft-fp configuration (representing embedded / kernel development).

It seems variations of this come up every so often, so I'll also link back to my statement from one of the previous times: [algorithm] new float/double to string algorithm - #2 by Vorpal (as well as the conversion that follows after and then runs out into the sand)

Note: I'm not saying that the library is bad, just that the bar from std is high, especially for code that ends up in no-std. It needs to work for every use case then.

2 Likes
3

TBH, what we really need is someone to figure out a language feature for things like the allocator shim so that it can be less special and we can use that mechanism for more things -- like this.

Then core can offer a default implementation that's a fine middle-ground, but people can plug in different things in their binaries depending on their needs: size-optimized ones if you only do this for a couple parameters in a CLI, one that calls out to the C library for embedded that has a C version already, a big-but-fast one for something doing a ton of floats in JSON, etc.

5 Likes
4

That would potentially be amazing for many other things too, one that comes to mind is being able to make mutex (and other locking primitives, as well as channels) use priority inheritance. That is a thorn in the side of anyone doing hard realtime on Linux currently.

2 Likes