c# - 为什么我的内存基准测试给出奇怪的结果？

Question

我最近一直在运行一些用 C# 编写的基本基准测试，试图确定为什么一些看似相同的 HyperV 远程工作站运行起来比其他工作站慢得多。他们在我运行的大多数基本测试中的结果完全相同，但是基本内存访问基准测试的结果(具体来说，将 2 维 1000x1000 double 组初始化为 0 所花费的时间)相差 40 倍。

为了进一步调查这个问题，我进行了其他几个实验来进一步缩小问题范围。使用呈指数增长的数组大小运行相同的测试(直到发生 OutOfMemoryException)显示各种远程之间没有差异，直到数组大小超过 1m，然后立即差异大约 40 倍。事实上，测试增量数组大小，初始化花费的时间与数组大小成比例增加，直到数组大小正好为 999999，然后在“慢速” Remote 上，花费的时间增加 900%，而在“快速” Remote 上，随着数组大小达到，它减少 70% 1000x1000。从那里开始，它继续按比例扩展。同样的现象也发生在 1m x 1 和 1 x 1m 的阵列大小上，尽管程度要小得多(改为 +50% 和 -30% 的变化。

有趣的是，将用于实验的数据类型更改为 float 似乎可以完全消除这种现象。在任何测试中， Remote 之间没有差异，即使在 1000*1000 和 2000*2000 断点上，所用时间似乎也完全成正比。另一个有趣的因素是我正在使用的本地工作站的行为似乎反射(reflect)了较慢的远程工作站的行为。

有没有人知道系统配置中的哪些设置可能会导致这种影响以及如何更改它，或者可以做些什么来进一步调试问题？

Answer 1

您必须牢记您真正测试的是什么。这肯定不是 .NET 程序分配数组元素的能力。这是非常快的，通常 yield 是大阵列的内存总线带宽，通常约为 37 GB/秒，具体取决于机器所具有的 RAM 类型，5 GB/秒，你今天可能遇到的最慢的类型(慢速时钟 DDR2一台旧机器)。

new 关键字仅在 Windows 等按需分页虚拟内存操作系统上分配地址空间。只是处理器的编号，每 4096 字节一个。

一旦您第一次开始分配元素，请求分页功能就会启动，您的代码会强制操作系统为数组分配 RAM。数组元素分配触发页面错误，数组中每 4096 个字节一个。或者你的数组有 512 个 double 。处理页面错误的成本包含在您的衡量中。

只有当操作系统有一个零初始化的 RAM 页面可供使用时，这才是顺利的。通常需要半微秒的脂肪，给予或接受。处理器仍然需要很多时间，当操作系统更新页面映射时它会停止。请记住，这只发生在第一个元素访问时，后续的访问很快，因为 RAM 页面仍然可用。通常。

当这样的 RAM 页面不可用时，不会一帆风顺。然后操作系统必须掠夺一个。在你的案例中，我能想到多达 4 种不同的场景:

• 页面可用但尚未由低优先级零页面线程进行零初始化。应该很快，不需要太多的努力。
• 需要从另一个进程中窃取一个页面，并且不需要保留该页面的内容。例如，发生在以前包含代码的页面上。也很快。
• 需要窃取一个页面，其内容需要保存在页面文件中。例如，发生在以前包含数据的页面上。一个硬页面错误，那个很痛。磁盘写入发生时，处理器将停止。
• 特定于您的方案，HyperV 管理器决定是时候从主机操作系统借用更多 RAM 了。前面的所有项目符号都适用于该操作系统，加上操作系统交互的开销。不知道这需要多少开销，也应该很痛苦。

您将击中哪一颗子弹是非常非常难以预测的。最重要的是，因为涉及的不仅仅是您的程序，机器上运行的任何其他程序也会影响它。还有一个内存效应，比如在你开始测试之前写一个大文件会产生严重的副作用，这是由等待磁盘的文件系统缓存使用 RAM 页引起的。或者另一个具有分配突发并耗尽零页面队列的进程。或者内存总线变得饱和，很容易做到，也可能受到主机操作系统的影响。等等。

总而言之，分析这段代码意义不大。任何事情都可能而且将会发生，而您没有合适的方法来预测它会发生。或者一个解决它的好方法，除了给 VM 大量 RAM 并且不在其上运行任何其他东西:) second 通过数组的分析结果将会很多更加稳定和有意义，现在不再涉及操作系统。