我在做一个调查,在计算性能的int,浮点数,双精度,十进制。我对结果很好奇。首先,我期望当我们做加号运算时,赢家将是int,但真实的是在截图上。
下面是我正在检查的代码。
public class PerformanceTest
{
[Benchmark]
public void CalcDouble()
{
double firstDigit = 135.543d;
double secondDigit = 145.1234;
double result = firstDigit + secondDigit;
}
[Benchmark]
public void CalcDecimal()
{
decimal firstDigit = 135.543m;
decimal secondDigit = 145.1234m;
decimal result = firstDigit + secondDigit;
}
[Benchmark]
public void Calcfloat()
{
float firstDigit = 135.543f;
float secondDigit = 145.1234f;
float result = firstDigit + secondDigit;
}
[Benchmark]
public void Calcint()
{
int firstDigit = 135;
int secondDigit = 145;
int result = firstDigit + secondDigit;
}
}
谁能告诉我这是怎么回事?谢谢你
我希望Int是赢家,但赢家是float。
2条答案
按热度按时间ix0qys7i1#
这显示了基准测试的问题,事情是 * 真的真的快 *;你可以通过 * 做更多的事情 * 来减慢速度-可选地使用
OperationsPerInvoke
来相应地缩放结果:更好的结果:
特别地,误差现在是平均值的舍入误差。
验证码:
h9a6wy2h2#
第一部分。基准测试的问题在于
C#编译器和即时(JIT)编译器都可以对您的代码执行各种优化。具体的优化集取决于这些编译器的特定版本,但默认情况下,应该有一些基本的代码转换。
示例中的一个优化称为constant folding;它能够冷凝
到
另一种优化称为dead code elimination。由于在基准测试中不使用计算结果,因此C#/JIT编译器能够完全消除此代码。因此,实际上,您可以像这样对空方法进行基准测试:
唯一的例外是CalcDecimal:由于Decimal是C#中的结构体(不是原始类型),C#/Roslyn编译器不够智能,无法完全消除计算(目前;这在将来可以改进)。
的上下文中详细讨论了这两种优化。NET基准测试(第65页:Dead Code Elimination,第69页:常数折叠)。这两个主题都属于“Common Benchmarking Pitfalls”一章,其中包含了更多可能扭曲基准测试结果的陷阱。
第二部分。BenchmarkDotNet结果
粘贴汇总表时,会剪切表下方的警告部分。我重新运行您的基准测试,以下是结果的扩展版本(默认情况下在BenchmarkDotNet结果中显示):
这些警告提供了对结果的宝贵见解。实际上,
CalcDouble
、Calcfloat
和Calcint
与空方法(如您在
Mean
列中看到的数字只是随机的CPU噪声,其持续时间低于一个CPU周期。假设你的CPU的频率是5GHz。这意味着单个CPU周期的持续时间约为0。2ns。没有什么可以比一个CPU周期更快地执行(如果我们谈论BenchmarkDotNet中默认测量的操作延迟;如果我们切换到吞吐量测量,我们可以获得“更快”的计算,这会产生各种效果,如instruction level parallelism,参见"Pro .NET Benchmarking",第440页)。CalcDouble
、Calcfloat
和Calcint
的“平均”值明显小于单个CPU周期的持续时间,因此实际比较它们没有意义。BenchmarkDotNet发现
Mean
列有问题。因此,除了汇总表下面的警告之外,它还添加了一个奖励列Median
(默认情况下是隐藏的),以突出显示所讨论的基准测试的零持续时间或空值。第三部分。可能的基准设计改进
设计这样一个基准测试的最好方法是使它与所考虑的实际工作负载相似。算术运算的实际性能是一个极其棘手的东西来衡量;它取决于许多外部因素(如我前面提到的指令级并行性)。详情请参见"Pro .NET Benchmarking"的第7章“CPU绑定的基准测试”;它有24个案例研究,提供了各种例子。评估算术运算的“纯”持续时间是一个有趣的技术挑战,但它不能适用于现实生活中的代码。
这里也是一些推荐的BenchmarkDotNet技巧来设计更好的基准测试:
1.将所有“常量”变量移动到公共字段/属性。在这种情况下,C#/JIT编译器将无法应用常量折叠(因为它事先不知道没有人会实际更改这些公共字段/属性的值)。
1.从
[Benchmark]
方法返回计算结果。这是要求BenchmarkDotNet防止死代码消除的方法。suggested approach by Marc Gravell将在一定程度上起作用。但是,它也可能存在一些其他问题:
1.不建议在for循环中使用固定的迭代次数,因为不同的JIT编译器可能会以不同的方式应用循环展开(另一个基准测试陷阱,参见"Pro .NET Benchmarking",第61页),这可能会扭曲某些环境中的结果。
1.请注意,添加人工循环会给基准测试增加一些性能成本。因此,可以使用这样一组基准测试来获得相对结果,但绝对值还包括循环开销("Pro .NET Benchmarking",第54页)。
1.据我所知,现代的C#/JIT编译器还没有聪明到完全消除这样的代码。但是,我们不能保证它不会被消除,因为它实际上总是返回相同的常数。未来版本的编译器可以足够智能地执行这样的优化(我相信一些Java运行时能够消除类似的基准测试)。因此,最好将所有常量移动到公共非常量字段/属性中,以防止这种情况。