C#中的内存布局优化

Question

免责声明:下面的措辞中可能存在一些误解,请纠正我,如果我误解了我的代码是在C#处理的那一刻我写的那一刻它看起来像零和一个

问题如下(这些是相关的):

在C#中我的数据结构和/或我的数据操作实现是否有任何方式,无论我是否使用优化技术都会对性能产生影响？

输出IL时编译器做了什么,它可靠吗？含义:如果我创建数据SOA将是IL中的SOA吗？总是？

当JIT读取IL时,我的数据结构会发生什么？它改变了吗？它是否自动优化以适合我的处理器？

cf:谈论C/C++

我知道这个演讲的目标是本机代码,并讨论处理器布局的细节与本机代码中的数据布局.

我也知道C#编译器和JIT编译器会针对这些问题优化我的东西.

基本上我想知道这些优化是否会对我的性能产生影响:

• SOA而不是AOS
• 向量访问模式(在内存中连续访问)
• 等等......你说出来......

我从事游戏开发工作并且性能至关重要,我们操作大量数据并且我们需要每秒至少执行24次,我不能让GC执行300毫秒的操作或者当我在任何地方访问/分配内存时试图检测3000个不同物体之间的碰撞

关于我读过的东西的参考,但没有真正回答这个问题:

• 优秀的Eric Lippert关于C#中的结构和值类型的文章(如果您认为值类型总是在C#中的堆栈中,请阅读它,您将其用于处理)

• 关于PerfView的优秀视频,用于跟踪您的GC行为及其对您的性能的影响

• 关于在C#中优化内存的最佳实践的问题(更重要的是它的答案)

但是那些没有回答相对于处理器和数据布局实现的性能成本.

---

在汉斯回答之后要走得更远:

当你说:"你可以追求SOA,但这没有帮助.是的,你的程序会因为所有结构复制而减速,并且以确定的方式这样做.但它并没有阻止下雨.你得到了最糟糕的两个,一个缓慢的程序和完全相同的停顿."

这并不意味着我的程序不会从SOA中获益,它会更快(可能),因为它将有助于处理我的数据.只是它本身对GC没有影响.

另一件事是,如果我不在我的数据布局中进行SOA或其他改进,编译器对我来说不会改进吗？我不能依靠编译器来处理那种事情？

Answer 1

担心 GC 就像担心今天是否会下雨一样。迟早要下雨，你无法阻止它。这是必需的，否则你就无法让草坪看起来很绿。你永远不想做的就是故意阻止下雨。因为如果你这样做，它就会像洪水一样倾泻而下，淹没那片美丽的草坪。持续的细雨就是你想要的。最好是在晚上你不注意的时候。

.NET GC 强烈支持这一点。只有小型 gen #0 和 #1 集合才会暂停您的程序。当您的代码继续执行时，昂贵的 gen#2 收集会在后台发生。最坏情况下的暂停会徘徊在接近一百微秒的地方。这与程序在现代操作系统上暂停的其他原因几乎没有区别。就像你的游戏循环暂时挂起一样，因为另一个更高优先级的内核线程需要运行。只是一场毛毛细雨，肉眼无法察觉。

您可以追求 SOA，但这没有帮助。是的，你的程序会因为所有的结构复制而变慢，并且是以确定性的方式进行的。但这并不能阻止雨。你会得到最糟糕的结果，一个缓慢的程序和完全相同的暂停。

不要担心下雨，只要确保它在正确的时间下雨即可。为了利用后台 GC，您需要对数据进行结构化，使其寿命非常短暂，这样它就可以在 gen #0/1 集合中轻松消失。或者寿命很长，因此它在第 2 代中找到了一个舒适的家并在那里停留了一段时间。一般来说，这是程序中非常常见的模式，尤其是在游戏中。您几乎不可能需要做任何事情。