Closed performanceautofiler[bot] closed 2 weeks ago
Likely caused by https://github.com/dotnet/runtime/pull/104506.
@matouskozak @tannergooding FYI
I think we should just revert that change then since there were no improvemens from it, only regressions
Do we know why it regressed?
I bet it has something to do with struct promotion, it's nice to see safe code to be faster than unnecessary unsafe
@EgorBot -arm64 -perf -commit 8d231b4e0f3b9459ac51cf6c7d801e56cb780f08 vs 01dbf511d03f17bff6ac3effc4c5aabaa597cf74 --disasm
using BenchmarkDotNet.Attributes;
public class Perf_Int128
{
private char[] _destination = new char[Int128.MinValue.ToString().Length];
public static IEnumerable<object> StringValues => Values.Select(value => value.ToString()).ToArray();
public static IEnumerable<object> Values => [Int128.MaxValue];
[Benchmark]
[ArgumentsSource(nameof(Values))]
public bool TryFormat(Int128 value) => value.TryFormat(new Span<char>(_destination), out _);
}
Looks like UInt64ToDecChars
was inlined in PR and ate some inlining budget so WriteTwoDigits
wasn't inlined. I think it's better to revert it than trying to fix the "unsafe" variant.
ate some inlining budget so WriteTwoDigits wasn't inlined
Regardless of what we do here, can we please re-investigate having AggressiveInlining mean "for the love of all that is good in this world always inline this if it's physically possible" so we stop having these cases where inlining budget means tiny helpers stop being inlined? I get that means some folks (possibly including us in some cases) that do insane things with AggressiveInlining might start to get worse performance, but they'll be getting what they asked for and can fix it.
Regardless of what we do here, can we please re-investigate having AggressiveInlining mean "for the love of all that is good in this world always inline this if it's physically possible" so we stop having these cases where inlining budget means tiny helpers stop being inlined?
Unfortunately, it's not a solution, we may inline all AggressiveInlining
and then stop inlining various Span.op_Implicit
inside them and other APIs which are currently don't have AggressiveInlining
, instead, we should've given up on a large method so everything inside of it had more chances to inline, etc.
Regardless of what we do here, can we please re-investigate having AggressiveInlining mean "for the love of all that is good in this world always inline this if it's physically possible" so we stop having these cases where inlining budget means tiny helpers stop being inlined?
Unfortunately, it's not a solution, we may inline all
AggressiveInlining
and then stop inlining variousSpan.op_Implicit
inside them and other APIs which are currently don't haveAggressiveInlining
, instead, we should've given up on a large method so everything inside of it had more chances to inline, etc.
It's not a solution even if things marked AggressiveInlining don't consume any inlining budget?
It's not a solution even if things marked AggressiveInlining don't consume any inlining budget?
Correct, imagine you have method A (root) and you inline stuff into it. You already inlined a lot and consumed 95% of your buget, then, you encounter this big method B
with AggressiveInlining
on it and inline it without reducing the budget - boom - you have no budget to inline any calls inside of it, even fairly trivial ones since you only have 5% (maybe for just one)
cc @AndyAyersMS
Tagging subscribers to this area: @dotnet/area-system-numerics See info in area-owners.md if you want to be subscribed.
I think we should just revert that change then since there were no improvemens from it, only regressions
@stephentoub -- Any objections to reverting Use Unsafe.BitCast
for Int128
↔UInt128
operators (#104506)?
I think it's better to revert it than trying to fix the "unsafe" variant.
Let's do both. We can revert for now to undo the regression, but we shouldn't need to second guess ourselves when using Bitcast.
Run Information
Regressions in System.Tests.Perf_Int128
Repro
General Docs link: https://github.com/dotnet/performance/blob/main/docs/benchmarking-workflow-dotnet-runtime.md