为什么 lambda 比 IL 注入的动态方法更快
本文关键字:动态 方法 注入 lambda IL 为什么 | 更新日期: 2023-09-27 18:37:10
我刚刚构建了动态方法 - 见下文(感谢SO用户)。看起来 Func 是作为动态方法创建的,IL 注入比 lambda 慢 2 倍。
有谁知道为什么?
(编辑:这是在VS2010中作为x64版本构建的。请从控制台运行它,而不是从Visual Studio F5内部运行它。
class Program
{
static void Main(string[] args)
{
var mul1 = IL_EmbedConst(5);
var res = mul1(4);
Console.WriteLine(res);
var mul2 = EmbedConstFunc(5);
res = mul2(4);
Console.WriteLine(res);
double d, acc = 0;
Stopwatch sw = new Stopwatch();
for (int k = 0; k < 10; k++)
{
long time1;
sw.Restart();
for (int i = 0; i < 10000000; i++)
{
d = mul2(i);
acc += d;
}
sw.Stop();
time1 = sw.ElapsedMilliseconds;
sw.Restart();
for (int i = 0; i < 10000000; i++)
{
d = mul1(i);
acc += d;
}
sw.Stop();
Console.WriteLine("{0,6} {1,6}", time1, sw.ElapsedMilliseconds);
}
Console.WriteLine("'n{0}...'n", acc);
Console.ReadLine();
}
static Func<int, int> IL_EmbedConst(int b)
{
var method = new DynamicMethod("EmbedConst", typeof(int), new[] { typeof(int) } );
var il = method.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Ldc_I4, b);
il.Emit(OpCodes.Mul);
il.Emit(OpCodes.Ret);
return (Func<int, int>)method.CreateDelegate(typeof(Func<int, int>));
}
static Func<int, int> EmbedConstFunc(int b)
{
return a => a * b;
}
}
这是输出(适用于 i7 920)
20
20
25 51
25 51
24 51
24 51
24 51
25 51
25 51
25 51
24 51
24 51
4.9999995E+15...
====
========================================================================================编辑 编辑编辑
编辑这是 dhtorpe 是正确的证明 - 更复杂的 lambda 将失去其优势。代码来证明这一点(这表明 Lambda 在 IL 注入方面具有完全相同的性能):
class Program
{
static void Main(string[] args)
{
var mul1 = IL_EmbedConst(5);
double res = mul1(4,6);
Console.WriteLine(res);
var mul2 = EmbedConstFunc(5);
res = mul2(4,6);
Console.WriteLine(res);
double d, acc = 0;
Stopwatch sw = new Stopwatch();
for (int k = 0; k < 10; k++)
{
long time1;
sw.Restart();
for (int i = 0; i < 10000000; i++)
{
d = mul2(i, i+1);
acc += d;
}
sw.Stop();
time1 = sw.ElapsedMilliseconds;
sw.Restart();
for (int i = 0; i < 10000000; i++)
{
d = mul1(i, i + 1);
acc += d;
}
sw.Stop();
Console.WriteLine("{0,6} {1,6}", time1, sw.ElapsedMilliseconds);
}
Console.WriteLine("'n{0}...'n", acc);
Console.ReadLine();
}
static Func<int, int, double> IL_EmbedConst(int b)
{
var method = new DynamicMethod("EmbedConstIL", typeof(double), new[] { typeof(int), typeof(int) });
var log = typeof(Math).GetMethod("Log", new Type[] { typeof(double) });
var il = method.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Ldc_I4, b);
il.Emit(OpCodes.Mul);
il.Emit(OpCodes.Conv_R8);
il.Emit(OpCodes.Ldarg_1);
il.Emit(OpCodes.Ldc_I4, b);
il.Emit(OpCodes.Mul);
il.Emit(OpCodes.Conv_R8);
il.Emit(OpCodes.Call, log);
il.Emit(OpCodes.Sub);
il.Emit(OpCodes.Ret);
return (Func<int, int, double>)method.CreateDelegate(typeof(Func<int, int, double>));
}
static Func<int, int, double> EmbedConstFunc(int b)
{
return (a, z) => a * b - Math.Log(z * b);
}
}
常数 5 是原因。这到底是为什么呢?原因:当 JIT 知道常数为 5 时,它不会发出imul
指令,而是发出 lea [rax, rax * 4]
。这是一个众所周知的程序集级优化。但由于某种原因,此代码执行速度较慢。优化是一种悲观。
发出闭包的 C# 编译器阻止了 JIT 以这种特定方式优化代码。
证明:将常量更改为56878567,性能将更改。检查 JIT 代码时,您可以看到现在使用了 imul。
我设法通过将常量 5 硬编码到 lambda 中来解决这个问题,如下所示:
static Func<int, int> EmbedConstFunc2(int b)
{
return a => a * 5;
}
这允许我检查JITed x86。
旁注:.NET JIT 不会以任何方式内联委托调用。只是提到这一点,因为评论中错误地推测就是这种情况。
侧节点 2:为了获得完整的 JIT 优化级别,您需要在发布模式下编译并在不附加调试器的情况下启动。调试器阻止执行优化,即使在发布模式下也是如此。
旁注3:虽然EmbedConstFunc包含一个闭包,并且通常比动态生成的方法慢,但这种"lea"优化的效果会造成更大的损害,最终会变慢。
lambda并不比DynamicMethod快。它基于。但是,静态方法比实例方法快,但静态方法的委托创建比实例方法的委托创建慢。Lambda 表达式构建一个静态方法,但通过添加"闭包"作为第一个 paameter 来像实例方法一样使用它。委托给静态方法"pop"堆栈,以在"mov"到真正的"IL主体"之前摆脱不需要的"this"实例。例如,在委托的情况下,方法"IL 正文"被直接命中。这就是为什么委托给由 lambda 表达式构建的假设静态方法更快(可能是委托模式代码共享 beetween 实例/静态方法的副作用)
通过将未使用的第一个参数(例如闭包类型)添加到 DynamicMethod 并使用显式目标实例调用 CreateDelegate(可以使用 null),可以避免性能问题。
var myDelegate = DynamicMethod.CreateDelegate(MyDelegateType, null) as MyDelegateType;
http://msdn.microsoft.com/fr-fr/library/z43fsh67(v=vs.110).aspx
通磊
鉴于仅在未附加调试器的发布模式下运行时存在性能差异,我能想到的唯一解释是 JIT 编译器能够对它无法为发出的 IL 动态函数执行的 lambda 表达式进行本机代码优化。
针对发布模式(优化)进行编译并在未附加调试器的情况下运行,lambda 始终比生成的 IL 动态方法快 2 倍。
运行相同的发布模式优化版本并将调试器附加到进程,会将 lambda 性能降至与生成的 IL 动态方法相当或更差。
这两个运行之间的唯一区别在于 JIT 的行为。 调试进程时,JIT 编译器会禁止显示许多本机代码生成优化,以保留本机指令到 IL 指令到源代码行号映射以及其他关联,这些关联将被积极的本机指令优化所破坏。
仅当输入表达式图(在本例中为 IL 代码)与某些非常特定的模式和条件匹配时,编译器才能应用特殊情况优化。JIT 编译器显然具有 lambda 表达式 IL 代码模式的特殊知识,并且发出的 lambda 代码与"普通"IL 代码不同。
您的 IL 指令很可能与导致 JIT 编译器优化 lambda 表达式的模式不完全匹配。例如,IL 指令将 B 值编码为内联常量,而类似的 lambda 表达式从内部捕获的变量对象实例加载字段。即使生成的 IL 要模拟 C# 编译器生成的 lambda 表达式 IL 的捕获字段模式,它仍然可能不够"接近",无法接收与 lambda 表达式相同的 JIT 处理。
如评论中所述,这很可能是由于内联 lambda 以消除调用/返回开销。如果是这种情况,我希望看到这种性能差异在更复杂的 lambda 表达式中消失,因为内联通常只保留给最简单的表达式。