将非托管C ++与F＃混合用于物理学：值得吗？

Question

我将开始使用DirectX SDK在非托管C ++中编写3D游戏。这将涉及大量的物理和数学，虽然我无法预测它会有多复杂（例如，我不知道我是否会将它并行化）。我想，由于F＃的incredibly awesome units of measure feature，以及它的功能性，因此可以很好地并行化，我可以编写一个F＃库来进行游戏的数学密集型计算。但是：

• 我对C ++缺乏经验，从不与托管代码接口。我不知道这会是多么艰难。
• 我不知道在每个数学密集型计算（每个游戏迭代必须至少运行一个物理方程式）时，跳入和跳出托管DLL的速度会有多大？
• 我不确定计量单位和简单并行化的收益是否值得。我的意思是，如果它只是数学，那么无论如何都要很容易用C ++编程（没有任何副作用，如果我记得在C ++中有一个pure关键字可能不允许副作用或什么？） - 如果我非常小心（我知道我只会使用公制单位），我想如果没有计量单位我就可以做到。

值得吗？混合托管和非托管代码是一种常见的做法吗？游戏怎么样？它会成为一个瓶颈吗？它会让我的抽奖代码变得恐怖而复杂吗？如果你打开一个VC ++项目并看到了这种情况 - 你的脸会是什么样的（:) :( D:等）

Answer 1

从托管代码跳转到非托管代码，或从单个操作的非托管代码跳转到托管代码代价高昂，对于单实例代价高昂的操作而言不值得。也就是说，在调用矩阵乘法时，托管到非托管或非托管到托管成本将高于代码本机实现中的乘法成本，尽管批处理操作会有所帮助。

对于您正在讨论的内容，以这种方式使用F＃不会产生任何明显的好处。还应该注意，您已经有几个数学库可供使用，例如XNAMath（随DXSDK一起提供）用于基本的图形转换。

在物理学的最后，您应该更喜欢使用物理中间件解决方案（PhysX，Bullet等），因为它们更加成熟，经过良好测试，并且从长远来看通常会简化开发。除了学习如何做之外，不建议编写自己的物理实现。