Consider implementing Grisu3 algorithm for double.ToString()

[mazong1123]

As we have implemented Dragon4 in dotnet/coreclr#12894 , we have a good start to improve the performance of double.ToString().

Although Dragon4 makes current double.ToString() much faster than previous implementation, we could do better. The algorithm Grisu3 introduced in this paper eliminated the big integer arithmetic so that it's much faster than Dragon4. However, not all numbers are applicable for using Grisu3. For those exclusive numbers, we can fall back to Dragon4. Quote from the paper:

As a consequence
Grisu3 is incomplete and will fail for some percentage of its input.
Given 11 extra bits roughly 99.5% are processed correctly and
are thus guaranteed to be optimal (with respect to shortness and
rounding). The remaining 0.5% are rejected and need to be printed
by another printing algorithm (like Dragon4).

Note Google's V8 engine has already adopted this algorithm. @tannergooding @tarekgh @jkotas I'm wondering is it a good timing for diving into this algorithm - I need sometime to do POC for it or in case of any concern from you guys.

[tarekgh]

@mazong1123 we can give it a try and have the implementation and measurement ready then we can decide if it is worth to have it if proven there is noticeable perf improvement.

Is there any source talking about how much perf improvement comparing Grisu3 with Dargon4?

[tannergooding]

The paper claims Grisu is up to 4x faster. I'm not sure if Grisu3 is faster or slower than that (although I would imagine slightly slower since it appears to use 11 additional bits, instead of just 2, and validates the answer is correct).

The paper also claims to be correct for 99.5% of numbers and needs to fallback for the remaining .5% (those will definitely be slower, since they will need to be entirely recomputed using the current algorithm).

It is probably important to know where the 0.5% of numbers fall, since that is still a fairly large group of numbers. If they are subnormal or extremely large numbers, it probably doesn't matter too much. But if they frequently fall in the -1.0 to 1.0 (inclusive) range, then it means common numbers will be frequently recomputed (0.5% is 21.4 million single-precision values or 92.2 quadrillion double-precision values).