Почему приведение структуры через Pointer происходит медленно, а Unsafe.As - быстро?
Фон
Я хотел сделать несколько целочисленных structs (т.е. 32 и 64 бита), которые легко конвертируются в / из примитивных неуправляемых типов одинакового размера (т.е. Int32 а также UInt32 для 32-битной структуры в частности).
Структуры тогда предоставят дополнительную функциональность для манипулирования / индексации битов, которая недоступна для целочисленных типов напрямую. В основном, как своего рода синтаксический сахар, улучшающий читабельность и простоту использования.
Важной частью, однако, была производительность, в которой, по сути, должна быть нулевая стоимость этой дополнительной абстракции (в конце дня ЦП должен "видеть" те же биты, как если бы он имел дело с примитивными целыми числами).
Образец структуры
Ниже приведено только самое основное struct Я придумал. Он не обладает всеми функциональными возможностями, но достаточен для иллюстрации моих вопросов:
[StructLayout(LayoutKind.Explicit, Pack = 1, Size = 4)]
public struct Mask32 {
[FieldOffset(3)]
public byte Byte1;
[FieldOffset(2)]
public ushort UShort1;
[FieldOffset(2)]
public byte Byte2;
[FieldOffset(1)]
public byte Byte3;
[FieldOffset(0)]
public ushort UShort2;
[FieldOffset(0)]
public byte Byte4;
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static unsafe implicit operator Mask32(int i) => *(Mask32*)&i;
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static unsafe implicit operator Mask32(uint i) => *(Mask32*)&i;
}
Тест
Я хотел проверить производительность этой структуры. В частности, я хотел посмотреть, сможет ли он так же быстро получить отдельные байты, если я буду использовать обычную побитовую арифметику: (i >> 8) & 0xFF (например, получить 3-й байт).
Ниже вы увидите эталонный тест, который я придумал:
public unsafe class MyBenchmark {
const int count = 50000;
[Benchmark(Baseline = true)]
public static void Direct() {
var j = 0;
for (int i = 0; i < count; i++) {
//var b1 = i.Byte1();
//var b2 = i.Byte2();
var b3 = i.Byte3();
//var b4 = i.Byte4();
j += b3;
}
}
[Benchmark]
public static void ViaStructPointer() {
var j = 0;
int i = 0;
var s = (Mask32*)&i;
for (; i < count; i++) {
//var b1 = s->Byte1;
//var b2 = s->Byte2;
var b3 = s->Byte3;
//var b4 = s->Byte4;
j += b3;
}
}
[Benchmark]
public static void ViaStructPointer2() {
var j = 0;
int i = 0;
for (; i < count; i++) {
var s = *(Mask32*)&i;
//var b1 = s.Byte1;
//var b2 = s.Byte2;
var b3 = s.Byte3;
//var b4 = s.Byte4;
j += b3;
}
}
[Benchmark]
public static void ViaStructCast() {
var j = 0;
for (int i = 0; i < count; i++) {
Mask32 m = i;
//var b1 = m.Byte1;
//var b2 = m.Byte2;
var b3 = m.Byte3;
//var b4 = m.Byte4;
j += b3;
}
}
[Benchmark]
public static void ViaUnsafeAs() {
var j = 0;
for (int i = 0; i < count; i++) {
var m = Unsafe.As<int, Mask32>(ref i);
//var b1 = m.Byte1;
//var b2 = m.Byte2;
var b3 = m.Byte3;
//var b4 = m.Byte4;
j += b3;
}
}
}
Byte1(), Byte2(), Byte3(), а также Byte4() это просто методы расширения, которые вставляются и просто получают n-й байт, выполняя побитовые операции и приведение:
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte1(this int it) => (byte)(it >> 24);
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte2(this int it) => (byte)((it >> 16) & 0xFF);
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte3(this int it) => (byte)((it >> 8) & 0xFF);
[DebuggerStepThrough, MethodImpl(MethodImplOptions.AggressiveInlining)]
public static byte Byte4(this int it) => (byte)it;
РЕДАКТИРОВАТЬ: Исправлен код, чтобы убедиться, что переменные действительно используются. Также закомментировано 3 из 4 переменных, чтобы реально протестировать приведение структуры / доступ к элементу, а не использовать переменные.
Результаты, достижения
Я запускал их в сборке Release с оптимизацией для x64.
Intel Core i7-3770K CPU 3.50GHz (Ivy Bridge), 1 CPU, 8 logical cores and 4 physical cores
Frequency=3410223 Hz, Resolution=293.2360 ns, Timer=TSC
[Host] : .NET Framework 4.6.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.6.1086.0
DefaultJob : .NET Framework 4.6.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.6.1086.0
Method | Mean | Error | StdDev | Scaled | ScaledSD |
------------------ |----------:|----------:|----------:|-------:|---------:|
Direct | 14.47 us | 0.3314 us | 0.2938 us | 1.00 | 0.00 |
ViaStructPointer | 111.32 us | 0.6481 us | 0.6062 us | 7.70 | 0.15 |
ViaStructPointer2 | 102.31 us | 0.7632 us | 0.7139 us | 7.07 | 0.14 |
ViaStructCast | 29.00 us | 0.3159 us | 0.2800 us | 2.01 | 0.04 |
ViaUnsafeAs | 14.32 us | 0.0955 us | 0.0894 us | 0.99 | 0.02 |
РЕДАКТИРОВАТЬ: Новые результаты после исправления кода:
Method | Mean | Error | StdDev | Scaled | ScaledSD |
------------------ |----------:|----------:|----------:|-------:|---------:|
Direct | 57.51 us | 1.1070 us | 1.0355 us | 1.00 | 0.00 |
ViaStructPointer | 203.20 us | 3.9830 us | 3.5308 us | 3.53 | 0.08 |
ViaStructPointer2 | 198.08 us | 1.8411 us | 1.6321 us | 3.45 | 0.06 |
ViaStructCast | 79.68 us | 1.5478 us | 1.7824 us | 1.39 | 0.04 |
ViaUnsafeAs | 57.01 us | 0.8266 us | 0.6902 us | 0.99 | 0.02 |
Вопросы
Результаты тестов были для меня неожиданными, и поэтому у меня есть несколько вопросов:
РЕДАКТИРОВАТЬ: после изменения кода остается меньше вопросов, так что переменные действительно используются.
- Почему указатель материал
такмедленный? Почему бросок занимает вдвое больше базового случая? Разве неявные / неявные операторы не встроены?- Как же новый
System.Runtime.CompilerServices.UnsafeПакет (v. 4.5.0) так быстро? Я думал, что это по крайней мере будет включать вызов метода... - В более общем смысле, как я могу сделать по существу структуру с нулевой стоимостью, которая бы просто действовала как "окно" в некоторую память или как примитивный тип biggish типа
UInt64чтобы я мог более эффективно манипулировать / читать эту память? Какова лучшая практика здесь?
2 ответа
Ответ на этот вопрос заключается в том, что JIT-компилятор может сделать некоторые оптимизации лучше, когда вы используете Unsafe.As(),
Unsafe.As() реализовано очень просто так:
public static ref TTo As<TFrom, TTo>(ref TFrom source)
{
return ref source;
}
Это оно!
Вот тестовая программа, которую я написал, чтобы сравнить это с кастингом:
using System;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
namespace Demo
{
[StructLayout(LayoutKind.Explicit, Pack = 1, Size = 4)]
public struct Mask32
{
[FieldOffset(3)]
public byte Byte1;
[FieldOffset(2)]
public ushort UShort1;
[FieldOffset(2)]
public byte Byte2;
[FieldOffset(1)]
public byte Byte3;
[FieldOffset(0)]
public ushort UShort2;
[FieldOffset(0)]
public byte Byte4;
}
public static unsafe class Program
{
static int count = 50000000;
public static int ViaStructPointer()
{
int total = 0;
for (int i = 0; i < count; i++)
{
var s = (Mask32*)&i;
total += s->Byte1;
}
return total;
}
public static int ViaUnsafeAs()
{
int total = 0;
for (int i = 0; i < count; i++)
{
var m = Unsafe.As<int, Mask32>(ref i);
total += m.Byte1;
}
return total;
}
public static void Main(string[] args)
{
var sw = new Stopwatch();
sw.Restart();
ViaStructPointer();
Console.WriteLine("ViaStructPointer took " + sw.Elapsed);
sw.Restart();
ViaUnsafeAs();
Console.WriteLine("ViaUnsafeAs took " + sw.Elapsed);
}
}
}
Результаты, которые я получаю на своем компьютере (сборка выпуска x64), таковы:
ViaStructPointer took 00:00:00.1314279
ViaUnsafeAs took 00:00:00.0249446
Как вы видете, ViaUnsafeAs действительно намного быстрее.
Итак, давайте посмотрим, что сгенерировал компилятор:
public static unsafe int ViaStructPointer()
{
int total = 0;
for (int i = 0; i < Program.count; i++)
{
total += (*(Mask32*)(&i)).Byte1;
}
return total;
}
public static int ViaUnsafeAs()
{
int total = 0;
for (int i = 0; i < Program.count; i++)
{
total += (Unsafe.As<int, Mask32>(ref i)).Byte1;
}
return total;
}
ОК, там нет ничего очевидного. Но как насчет IL?
.method public hidebysig static int32 ViaStructPointer () cil managed
{
.locals init (
[0] int32 total,
[1] int32 i,
[2] valuetype Demo.Mask32* s
)
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: ldc.i4.0
IL_0003: stloc.1
IL_0004: br.s IL_0017
.loop
{
IL_0006: ldloca.s i
IL_0008: conv.u
IL_0009: stloc.2
IL_000a: ldloc.0
IL_000b: ldloc.2
IL_000c: ldfld uint8 Demo.Mask32::Byte1
IL_0011: add
IL_0012: stloc.0
IL_0013: ldloc.1
IL_0014: ldc.i4.1
IL_0015: add
IL_0016: stloc.1
IL_0017: ldloc.1
IL_0018: ldsfld int32 Demo.Program::count
IL_001d: blt.s IL_0006
}
IL_001f: ldloc.0
IL_0020: ret
}
.method public hidebysig static int32 ViaUnsafeAs () cil managed
{
.locals init (
[0] int32 total,
[1] int32 i,
[2] valuetype Demo.Mask32 m
)
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: ldc.i4.0
IL_0003: stloc.1
IL_0004: br.s IL_0020
.loop
{
IL_0006: ldloca.s i
IL_0008: call valuetype Demo.Mask32& [System.Runtime.CompilerServices.Unsafe]System.Runtime.CompilerServices.Unsafe::As<int32, valuetype Demo.Mask32>(!!0&)
IL_000d: ldobj Demo.Mask32
IL_0012: stloc.2
IL_0013: ldloc.0
IL_0014: ldloc.2
IL_0015: ldfld uint8 Demo.Mask32::Byte1
IL_001a: add
IL_001b: stloc.0
IL_001c: ldloc.1
IL_001d: ldc.i4.1
IL_001e: add
IL_001f: stloc.1
IL_0020: ldloc.1
IL_0021: ldsfld int32 Demo.Program::count
IL_0026: blt.s IL_0006
}
IL_0028: ldloc.0
IL_0029: ret
}
Ага! Единственная разница здесь заключается в следующем:
ViaStructPointer: conv.u
ViaUnsafeAs: call valuetype Demo.Mask32& [System.Runtime.CompilerServices.Unsafe]System.Runtime.CompilerServices.Unsafe::As<int32, valuetype Demo.Mask32>(!!0&)
ldobj Demo.Mask32
На первый взгляд, вы ожидаете conv.u быть быстрее, чем две инструкции, используемые для Unsafe.As, Тем не менее, кажется, что JIT-компилятор способен оптимизировать эти две инструкции гораздо лучше, чем один conv.u,
Разумно спросить, почему это так - к сожалению, у меня пока нет ответа на этот вопрос! Я почти уверен, что призыв к Unsafe::As<>() в настоящее время используется JITTER, а JIT оптимизируется.
Есть некоторая информация о Unsafe Оптимизация класса здесь.
Обратите внимание, что IL, сгенерированный для Unsafe.As<> это просто так:
.method public hidebysig static !!TTo& As<TFrom, TTo> (
!!TFrom& source
) cil managed aggressiveinlining
{
.custom instance void System.Runtime.Versioning.NonVersionableAttribute::.ctor() = (
01 00 00 00
)
IL_0000: ldarg.0
IL_0001: ret
}
Теперь я думаю, что становится понятнее, почему JITTER может так хорошо это оптимизировать.
Когда вы берете локальный адрес, jit обычно должен хранить его в стеке. Это тот случай, здесь. в ViaPointer версия i хранится в стеке. в ViaUnsafe, i копируется в temp, а temp сохраняется в стеке. Первый медленнее, потому что i также используется для управления итерацией цикла.
Вы можете получить довольно близко к ViaUnsafe perf со следующим кодом, где вы явно делаете копию:
public static int ViaStructPointer2()
{
int total = 0;
for (int i = 0; i < count; i++)
{
int j = i;
var s = (Mask32*)&j;
total += s->Byte1;
}
return total;
}
ViaStructPointer took 00:00:00.1147793
ViaUnsafeAs took 00:00:00.0282828
ViaStructPointer2 took 00:00:00.0257589