Perf: double.ToString() 3x slower in some cases on Linux

[tarekgh]

We have enhanced the performance of Double.ToString when running on Linux. we used to be 7x slower on Linux than on Windows but now we are around 3x slower in some cases.this issue is tracking looking at Double.ToString performance to optimize more when running on Linux.

Note that, the current Double.ToString performance is slightly better than Windows in some cases (like when using Double.MaxValue /2) for instance.

#7700 is the original issue which has more details about what we have done so far and what more can be done.

[karelz]

@tarekgh just to clarify: Are we tracking improvements on Linux (title says that) or on Windows (first paragraph says that). Or both?

[tarekgh]

we are tracking to fix the perf on Linux as the title mention. thanks for the catch, I had typo in the first paragraph and I have fixed it.

[mazong1123]

Given an up-for-grabs label here, I'm wondering if anybody is working on this issue? If not, I can help on this.

[karelz]

It is not assigned to anyone, so no one is working on it (see Triage rules). Assigning to you ...

[tarekgh]

@mazong1123 thanks for looking at this. could you please share your thoughts before applying any changes?

[mazong1123]

@tarekgh I'm still reading the context and previous works you guys have done. Once the preparation finished, I'll list the overview of the issue from my perspective and then put my proposals here for discussion.

This should be done by 7/4 CST.

[mazong1123]

@tarekgh I've read the context of the double.ToString() performance issue. Following are my thoughts and plan. Please let me know if I missed anything or you have any input.

Overview

• Originally, double.ToString() on Linux is 7x slower than Windows because of the inefficient implementation of pal _ecvt, which is trying to emulate the behavior of Windows _ecvt.

• Re-write _ecvt by leveraging ecvt_r can get the double.ToString()'s performance back to Windows. However, ecvt_r breaks round tripping for edge cases (e.g. Double.MinValue) so we cannot use ecvt_r.

• Re-write _ecvt using the code of CoreRT DoubleToNumber can improve the performance (but not reach the Windows performance). We have applied the changes to unblock the customers.

Plan

• As mentioned by @jkotas in
  https://github.com/dotnet/coreclr/issues/10390#issuecomment-288549085 https://github.com/dotnet/coreclr/issues/10390#issuecomment-289457558 , the long term fix is to re-implement DoubleToNumber in an OS-independent manner, probably in full-managed code, so I'll try followings:

1. Write a demo based on the paper: https://www.cs.indiana.edu/~dyb/pubs/FP-Printing-PLDI96.pdf
2. If the demo is efficient as expected, apply it to DoubleToNumber.
3. If the performance improved as expected, convert the implementation to managed code.

[tarekgh]

@mazong1123 thanks for looking at that.

Write a demo based on the paper: https://www.cs.indiana.edu/~dyb/pubs/FP-Printing-PLDI96.pdf

2 things we need to confirm here if we are going to use this paper:

• there is no legal issues to implement this paper in open source. @terrajobst could you please help with this question?
• May be this paper implementation will require having a static data. we need to know how big this data would be as we are concerned about the size too.

thanks again for looking at this.

[mazong1123]

May be this paper implementation will require having a static data. we need to know how big this data would be as we are concerned about the size too.

Just to be clarified:

• Are you concerning about the size of data stored in static variables of C/C++ code?
• Do we have any specification/guideline with details of the size constrain?

[tarekgh]

Are you concerning about the size of data stored in static variables of C/C++ code?

Any data that increase the size of the net core on the disk will be a concern. If the data is really small (e.g. small arrays or static data). But if the data is few KB's then we need to look at that and evaluate the benefits. We had some work to optimize the size of the net core on the disk.

CC @jkotas

[jkotas]

I would worry about speed and correctness first. Once you have prototype that is fast and correct, we will worry about the rest (disk footprint, license, etc.)

[mazong1123]

@jkotas I'll write a demo first so that we can examine the correctness and speed. If it does not work as expected, we can have a quick turnaround.

BTW, do you have any idea other than trying the paper?

[mazong1123]

@jkotas @tarekgh I've prototype the paper roughly. Before I go further, I'd like to share the information I've learnt so far. With the algorithm,

1. double.MinValue can be exactly converted to a string -17976931348623157 with an exponent value 308, same as full .net framework 4.6.1 and .net core 2.0.0-preview2-005905 using double.ToString("R"), but is more accurarte than using double.ToString(), whose result is -1.79769313486232E+308;

2. The number 7.9228162514264338E+28 which was mentioned in https://github.com/dotnet/coreclr/issues/10390#issuecomment-290457104 can be converted to a string 7922816251426434 with an exponent value 28, which is less accurate comparing to full .net framework 4.6.1 and .net core 2.0.0-preview2-005905 using double.ToString("R"), whose output is 7.9228162514264338E+28, but is more accurate comparing to using double.ToString(), whose output is 7.92281625142643E+28

So I believe generally, the algorithm is more accurate than current implementation, but I need to adopt the double.ToString("R") implementation to my prototype and run the test cases again.

@tarekgh BTW, in https://github.com/dotnet/coreclr/issues/10390#issuecomment-291011320 , when testing double.MinValue against evct_r implementation, were you using double.ToString() or double.ToString("R")? I'm asking because even full .net framework 4.6.1 and .net core 2.0.0-preview2-005905 will produce the wrong number when using double.ToString() to convert double.MinValue.