Is it possible to write zero cost wrappers around doubles, for dimensional annotation purposes? #74475
-
|
My attempts at wrapping doubles in dimensionally typed wrappers are O(5x) slower than raw doubles. I have previously asked whether this could be improved at https://stackoverflow.com/questions/78696148/wrap-doubles-without-overhead-in-csharp (without genetics, which I use for the actual dimensional units, but even then it's 4x slower) Is there anything I could do to speed things up? If not, would it be a reasonable feature request to ask for improvements here? My previous attempt (copied from the stackoverflow post where it was recommended I post here), with BenchmarkDotNet code that exhibits a 4x slowdown: using System;
using System.Linq;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using NUnit.Framework;
namespace MyBenchmark;
public readonly struct MyDouble
{
public readonly double Value;
public MyDouble(double value)
{
Value = value;
}
public static MyDouble operator +(MyDouble self, MyDouble value)
{
return new MyDouble(self.Value + value.Value);
}
public static MyDouble operator *(MyDouble self, double value)
{
return new MyDouble(self.Value * value);
}
}
public class DoubleBenchmark
{
private const int N = 1_000_000;
private readonly double[] _data;
private readonly double[] _workspace;
private readonly MyDouble[] _typedData;
private readonly MyDouble[] _typedWorkspace;
public DoubleBenchmark()
{
_data= new double[N];
_workspace = new double[N];
_typedWorkspace = new MyDouble[N];
var rand = new Random(0);
for (var i = 0; i < N; i++)
{
_data[i] = rand.NextDouble();
}
_typedData = _data.Select(x => new MyDouble(x)).ToArray();
}
[Benchmark]
public MyDouble TypedDoubles()
{
var d = new MyDouble(0);
for (var i = 0; i < N; i++)
{
d += _typedData[i] * 3;
_typedWorkspace[i] = d * 2 + new MyDouble(1);
}
var e = new MyDouble(0);
for (var i = 0; i < N; i++)
{
e += _typedWorkspace[i];
}
return e;
}
[Benchmark]
public MyDouble ManuallyInlinedTypedDoubles()
{
var d = new MyDouble(0);
for (var i = 0; i < N; i++)
{
d = new MyDouble(d.Value + _typedData[i].Value * 3);
_typedWorkspace[i] = new MyDouble(d.Value * 2 + 1);
}
var e = new MyDouble(0);
for (var i = 0; i < N; i++)
{
e = new MyDouble(e.Value + _typedWorkspace[i].Value);
}
return e;
}
[Benchmark]
public double Doubles()
{
var d = 0d;
for (var i = 0; i < N; i++)
{
d += _data[i] * 3;
_workspace[i] = d * 2 + 1;
}
var e = 0d;
for (var i = 0; i < N; i++)
{
e += _workspace[i];
}
return e;
}
[Test, Explicit]
public static void RunBenchmarks()
{
BenchmarkRunner.Run<DoubleBenchmark>();
}
[Test, Explicit]
public static void EqualResults()
{
var a = new DoubleBenchmark();
Console.WriteLine((a.TypedDoubles().Value, a.Doubles(), a.ManuallyInlinedTypedDoubles().Value));
if (Math.Abs(a.TypedDoubles().Value - a.Doubles()) > 0 ||
Math.Abs(a.TypedDoubles().Value - a.ManuallyInlinedTypedDoubles().Value) > 1e-16)
{
throw new Exception("Different results");
}
}
} |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
This question lacks necessary information. What approach are you currently taking? Where is it slow? What part of that slowness is due to Roslyn? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I've copied the benchmark code I was running into this post (this is copied from my stackoverflow question). I don't know where it is slow and to what extent this is due to Roslyn. |
Beta Was this translation helpful? Give feedback.
-
|
Closing out as out of scope. If you determine this is due to anything roslyn is doing, please feel free to open an issue with the relevant information. Tagging @tannergooding in case he has some ideas though. My guess is that this isn't related to anything Roslyn does (we should be emitting idiomatic IL for all of that). So it's possibly due to how the runtime analyzes and optimize simple struct wrappers. |
Beta Was this translation helpful? Give feedback.
-
|
Zero-cost wrappers in general are a complex topic and there is no definitive answer because it is often dependent on the ABI (application binary interface) that exists for the underlying C runtime. In general, It used to be that structs with single-float fields could not be "promoted" (an optimization) due to such ABI differences, but I resolved that in the .NET 8 timeframe: dotnet/runtime#84627. -- This impacted all single-field floating-point wrapper structs, regardless of whether inlining happened or not. Even with that fix, however, there is still an ABI difference due to it being passed in an integer register rather than a floating-point register and thus causing data to need to be moved from the floating-point and into the general-purpose registers and then back again, across the call boundary (which is only an issue if inlining can't occur). There's some other general pessimizations that can happen as well if you aren't careful (but which are again mostly impactful if inlining can't occur). For example, instance methods require a hidden In this case, .NET 8 and .NET 9 both give numbers similar to the following, so my expectation is that you're running on .NET 6, is that correct? .NET 6 gives the following, which is expected due to the lack of struct promotion: |
Beta Was this translation helpful? Give feedback.
-
|
@tannergooding Thanks for your brilliant and comprehensive answer. I am on .NET6 indeed and am excited to hear about the significant performance gains to come for free when we eventually move onto .NET8 |
Beta Was this translation helpful? Give feedback.
Zero-cost wrappers in general are a complex topic and there is no definitive answer because it is often dependent on the ABI (application binary interface) that exists for the underlying C runtime.
In general,
struct S { T x; }andTare not equivalent at the ABI level and while they often do get passed around the same, there are many cases that they may not and that can lead to deficiencies.It used to be that structs with single-float fields could not be "promoted" (an optimization) due to such ABI differences, but I resolved that in the .NET 8 timeframe: dotnet/runtime#84627. -- This impacted all single-field floating-point wrapper structs, regardless of whether inlining happened or not.