Consider using csFastFloat for faster FP parsing

[EgorBo]

See Daniel Lemire's (@lemire) blogpost: https://lemire.me/blog/2021/02/22/parsing-floating-point-numbers-really-fast-in-c - a super fast floating-point parsing algorithm which is up to 6 times faster than the BCL one for an average case (for invariant culture).

|                     Method |        FileName |      Mean |     Error |    StdDev |       Min | Ratio | Gen 0 | Gen 1 | Gen 2 | Allocated | MFloat/s |     MB/s |
|--------------------------- |---------------- |----------:|----------:|----------:|----------:|------:|------:|------:|------:|----------:|---------:|---------:|
|    FastFloat.ParseDouble() | data/canada.txt |  5.974 ms | 0.0060 ms | 0.0053 ms |  5.965 ms |  0.16 |     - |     - |     - |       2 B |    18.63 |   350.04 |
|             Double.Parse() | data/canada.txt | 37.459 ms | 0.2417 ms | 0.2142 ms | 37.003 ms |  1.00 |     - |     - |     - |      21 B |     3.00 |    56.43 |
|                            |                 |           |           |           |           |       |       |       |       |           |          |          |
|    FastFloat.ParseDouble() |   data/mesh.txt |  1.815 ms | 0.0144 ms | 0.0134 ms |  1.798 ms |  0.26 |     - |     - |     - |       1 B |    40.61 |   344.84 |
|             Double.Parse() |   data/mesh.txt |  6.911 ms | 0.1136 ms | 0.1062 ms |  6.758 ms |  1.00 |     - |     - |     - |       2 B |    10.81 |    91.75 |

The algorithm: https://arxiv.org/abs/2101.11408 (and https://nigeltao.github.io/blog/2020/eisel-lemire.html)
Its C# port (by @CarlVerret): https://github.com/CarlVerret/csFastFloat

The current implementation supports "scientific", "fixed" and "general" formats, and a custom decimal separator (single char)
what else is needed for a proper integration into dotnet/runtime?

The implementation takes roughly 25Kb (~10kb of it is spent here https://github.com/CarlVerret/csFastFloat/blob/master/csFastFloat/Constants/Constants.cs#L22 - can be converted to a ROS<byte>?) of IL byte code.

Go lang switched to that algorithm in 1.16 (see strconv https://golang.org/doc/go1.16#strconv)

/cc @tannergooding

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @tannergooding, @pgovind
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See Daniel Lemire's (@lemire) blogpost: https://lemire.me/blog/2021/02/22/parsing-floating-point-numbers-really-fast-in-c - a super fast floating-point parsing algorithm which is up to 6 times faster than the BCL one for an average case (for invariant culture).

|                     Method |        FileName |      Mean |     Error |    StdDev |       Min | Ratio | Gen 0 | Gen 1 | Gen 2 | Allocated | MFloat/s |     MB/s |
|--------------------------- |---------------- |----------:|----------:|----------:|----------:|------:|------:|------:|------:|----------:|---------:|---------:|
|    FastFloat.ParseDouble() | data/canada.txt |  5.974 ms | 0.0060 ms | 0.0053 ms |  5.965 ms |  0.16 |     - |     - |     - |       2 B |    18.63 |   350.04 |
|             Double.Parse() | data/canada.txt | 37.459 ms | 0.2417 ms | 0.2142 ms | 37.003 ms |  1.00 |     - |     - |     - |      21 B |     3.00 |    56.43 |
|                            |                 |           |           |           |           |       |       |       |       |           |          |          |
|    FastFloat.ParseDouble() |   data/mesh.txt |  1.815 ms | 0.0144 ms | 0.0134 ms |  1.798 ms |  0.26 |     - |     - |     - |       1 B |    40.61 |   344.84 |
|             Double.Parse() |   data/mesh.txt |  6.911 ms | 0.1136 ms | 0.1062 ms |  6.758 ms |  1.00 |     - |     - |     - |       2 B |    10.81 |    91.75 |

C# port of the algorithm (by @CarlVerret): https://github.com/CarlVerret/csFastFloat

The current implementation supports "scientific", "fixed" and "general" formats, and a custom decimal separator (single char)
what else is needed for a proper integration into dotnet/runtime?

The implementation takes roughly 25Kb (~10kb of it is spent here https://github.com/CarlVerret/csFastFloat/blob/master/csFastFloat/Constants/Constants.cs#L22 - can be converted to a ROS<byte>?)

/cc @tannergooding

Author:	EgorBo
Assignees:	-
Labels:	area-System.Numerics, tenet-performance, untriaged
Milestone:	-

[tannergooding]

25kb is a lot of increase. That's basically a full 1% of the raw IL and 0.25% of the crossgen'd image.

Likewise, it looks like this algorithm only works for inputs up to 19 significant digits where-as we must be able to handle inputs up to 113 digits for float and 768 digits for double so we would still need to maintain our current code-paths as well.

It would be interesting to run this against our full test suite to see if any failures crop up.

Likewise, our current algorithm does try to optimize for the more common cases and after filling the NumberBuffer optimizes any case less than 15 significant digits and with an absolute exponent less than 22, so it might be interesting to find out if there is something simple we can do to improve things compared to CsFastFloat: https://source.dot.net/#System.Private.CoreLib/Number.NumberToFloatingPointBits.cs,07872ebd9c2d23ac

• Tthat is, for the cases that are less than 15 digits, is our slowdown just from filling in the number buffer or something similar?

[lemire]

@tannergooding

so we would still need to maintain our current code-paths as well.

I think that this is entirely correct.

This is how it was done in Go. They did not remove their code, they just inserted the fast path.

One way to understand the approach taken in csFastFloat is that we insert a fast path between Clinger's fast path (which you already use) and the full approach you rely upon. The trick is that this "second fast path" catches most of the "common inputs" so that the 'slower' path is rarely needed.

It is more useful than just for the 19 digit case, however. Even when the input exceed 19 digits, you can most often still use the fast path because 19 digits is often all you need to determine the number (you can often truncate). Please see Section 11 "Processing long numbers quickly" in the manuscript: https://arxiv.org/pdf/2101.11408.pdf Note that this is what the Go runtime does.

Otherwise, you must fall through to some other solution like your current own code. The csFastFloat has its own fall back currently, but it is likely that the current code in the runtime would be superior.

In practice, while users can provide 100s of digits, you should expect many (most?) use cases to use no more than 17 digits. There is no benefit to serializing double or float types to more than 17 digits if you want to later de-serialize them to float/double types. You still need to handle the case with 100s of digits, but it is should be expected to be common.

Of course, we are relying on a table has a cost (storage). In Go, this was discussed and they decided that it was a good trade-off.

It would be interesting to run this against our full test suite to see if any failures crop up.

The algorithm itself should be sound. It is has been in production for quite some time without issue and there is a complete mathematical derivation on arXiv. The csFastFloat library itself could use more thorough testing... Note however that we do have a rather good testing suite. A couple of minor issues were caught in the last few hours, but nothing that has to do with the algorithm or core processing.

[tannergooding]

Thanks for the reference. I'll give it an additional look through when I have some free time this afternoon.

It might be interesting to see if we can compress the table size somehow (many of the powers used in these cases are powers of 10 and have many trailing zeros for example; although this table looks to be power of 5 instead).
If we can reduce the overall size and have a perf win, then I'd have less concerns about taking something like this on.

[lemire]

@tannergooding

Yes. They are powers of 5 (for positive exponents) or reciprocal of powers of 5 (for negative exponents). We have that 10^50 = 2^50 * 5^50... so that there is no need to represent 2**50 formally. There are various ways one could trim that table but none that I have found appealing so far. One would be to restrict the application of the fast path to some powers only, instead of the full range. The rationale there might be that 1e200 and 1e-200 are relatively uncommon. This is not at all unreasonable, but it leaves you to decide where you set the threshold.

[lemire]

@tannergooding

Note that the table 10kB not 25kB. Roughly... the exponents go from -300 to 300... so about 600 exponents. You have 600 x 128 bits... is 9.6 kB. The 25kB is what you would need to store the full table which we do not do.

The manuscript addresses this issue...

To implement our algorithm, we use a precomputed table of powers of five and reciprocals. Though it uses 10 KiB, we should compare it with the original Gay’s implementation of strtod in C which uses 160 KiB and compiles to tens of kilobytes. Our table is used for parsing both 64-bit and 32-bit number

For comparison, on my current laptop...

❯ du -h /usr/local/share/dotnet/shared/Microsoft.NETCore.App
140M	/usr/local/share/dotnet/shared/Microsoft.NETCore.App

Sorry if I was slow to react... it took me hours to think "25kB??? that's not right". I need stronger coffee.

(Disclosure: I had a version with a 25kB for a time, but I decided that it was too wasteful.)

[EgorBo]

Note that the table 10kB not 25kB

25kb is the total size of the lib (code + that 10kb table), so it's a rough estimate of a size overhead for the corelib but I assume we can save a bit more

For comparison, on my current laptop...

That is a size of the SDK, typical .NET apps are self-contained nowadays, e.g. for web-assembly purposes every 10kb counts. But I assume we can have two implementations OptForSize (Wasm, Mobiles) and OptForSpeed (Desktop, Server) - we already do it for some other algorithms. I'd love to integrate this algorithm and run some JSON-parsing benchmarks.

[lemire]

25kb is the total size of the lib (code + that 10kb table), so it's a rough estimate of a size overhead for the corelib but I assume we can save a bit more

Most of the code in csFastFloat is for the fallback scenario which you would not need. It should be really tight once integrated in the runtime. I expect that 25kB is pessimistic.

[EgorBo]

25kb is the total size of the lib (code + that 10kb table), so it's a rough estimate of a size overhead for the corelib but I assume we can save a bit more

Most of the code in csFastFloat is for the fallback scenario which you would not need. It should be really tight once integrated in the runtime. I expect that 25kB is pessimistic.

Ah, makes sense!