-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deduplicate Binary Integer parsing logic #84582
Conversation
Tagging subscribers to this area: @dotnet/area-system-numerics Issue DetailsThis utilizes generic math to deduplicate most of the Binary Integer parsing logic. Doing so simplifies the code we need to maintain and will also make it easier to onboard UTF-8 support
|
0e4441f
to
0a83ed3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/libraries/System.Private.CoreLib/src/System/Number.Parsing.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Globalization/NumberFormatInfo.cs
Show resolved
Hide resolved
I've marked this as
NO-MERGE
|
Perf for RyuJITPerf_Byte
Perf_Int16
Perf_Int32
Perf_Int64
Perf_SByte
Perf_UInt16
Perf_UInt32
Perf_UInt64
|
MonoInterpreter is fine overall. It, however, really doesn't like changes such as: public static int Parse(string s)
{
- if (s == null) ThrowHelper.ThrowArgumentNullException(ExceptionArgument.s);
- return Number.ParseInt32(s, NumberStyles.Integer, NumberFormatInfo.CurrentInfo);
+ return Parse(s, NumberStyles.Integer, provider: null);
}
public static int Parse(string s, NumberStyles style, IFormatProvider? provider)
{
- NumberFormatInfo.ValidateParseStyleInteger(style);
- if (s == null) ThrowHelper.ThrowArgumentNullException(ExceptionArgument.s);
- return Number.ParseInt32(s, style, NumberFormatInfo.GetInstance(provider));
+ ArgumentNullException.ThrowIfNull(s);
+ return Parse(s.AsSpan(), style, provider);
}
public static int Parse(ReadOnlySpan<char> s, NumberStyles style = NumberStyles.Integer, IFormatProvider? provider = null)
{
NumberFormatInfo.ValidateParseStyleInteger(style);
return Number.ParseInt32(s, style, NumberFormatInfo.GetInstance(provider));
}
Is there anything we can do here to improve Mono for such scenarios? Being able to reduce the duplicated code here makes the code a lot more readable/maintainable and is a fairly standard practice throughout the BCL and in user code. Perf for MonoInterpreterPerf_Byte
Perf_Int16
Perf_Int32
Perf_Int64
Perf_SByte
Perf_UInt16
Perf_UInt32
Perf_UInt64
|
Similar overall results for MonoJIT Perf for MonoJITPerf_Byte
Perf_Int16
Perf_Int32
Perf_Int64
Perf_SByte
Perf_UInt16
Perf_UInt32
Perf_UInt64
|
CC. @SamMonoRT for input on the MonoInterpreter/MonoJIT results above? Its about a 30ns regression in the worst case. Reintroducing the validation duplication brings it down to about a 5ns regression, but brings back about 300 lines of code and makes the code atypical to a lot of other code in the BCL and community apps. We certainly can do this, if there are concerns about the regression; but long term this seems like another common pattern that Mono would ideally handle. -- Noting that outside the args validation, we are seeing perf wins in the interpreter for some of the |
Thanks @tannergooding - these regressions are acceptable given the scope of the changes. Are you targeting wasm-aot runs too? |
Haven't yet, let me get those numbers as well. |
@SamMonoRT, don't currently have a Unix machine setup so I won't be able to test until sometime next week. Trying to run on windows ends up hitting:
There are also a couple other quirks (which I tried working around), such as:
Ideally this would work and be testable on Windows as well, since that is one of the primary development environments for many users. |
@SamMonoRT, I'm not able to get the wasm-aot benchmarks working in WSL following the instructions given. Seeing:
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @tannergooding! I appreciate you reverting the throw helper approach and also gathering the mono perf numbers and looking at how different approaches have trade-offs.
Given that we've gathered perf numbers on a variety of coreclr and mono backends and the numbers looked good, and CI is green, and Tanner's tried to get wasm-aot numbers and is blocked from doing so, I think it's reasonable to merge. |
Will react to and handle any uncaught impact as needed. |
It looks like you are missing v8 engine. I have opened dotnet/performance#2974 to mention it in the workflow doc. |
Improvements on arm64: |
This utilizes generic math to deduplicate most of the Binary Integer parsing logic. Doing so simplifies the code we need to maintain and will also make it easier to onboard UTF-8 support