.net - 将非托管 C++ 与 F# 混合用于物理 : worth it?

Question

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

• 我在 C++ 方面缺乏经验，更不用说将它与托管代码进行交互了。我不知道这会有多辛苦。
• 我不知道对于每个数学密集型计算来说，跳入和跳出托管 DLL 的速度有多大(每次游戏迭代至少必须运行一个物理方程) .
• 我不确定测量单位的增益和简单的并行化是否值得。我的意思是，如果它只是数学，它无论如何都必须很容易在 C++ 中进行线程化(实际上没有任何副作用，如果我记得 C++ 中有一个 pure 关键字，也许它不允许副作用或其他什么？ ) -- 我想如果我真的很小心的话，我可以不用度量单位(我知道我只会使用公制单位)。

那么值得吗？混合托管和非托管代码是一种常见的做法吗？游戏呢？会不会成为瓶颈？它会让我的绘图代码变得可怕和令人费解吗？如果您打开一个 VC++ 项目并看到这种情况发生——您的脸会是什么样子 (:) :( D:, etc)

Answer 1

从托管代码跳到非托管代码，或者从非托管代码跳到托管代码以进行单个操作的成本很高，对于单实例成本高昂的操作来说不值得。也就是说，调用矩阵乘法时托管到非托管或非托管到托管的成本将高于代码 native 实现中的乘法成本，尽管批处理操作有所帮助。

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

在物理方面，您应该更喜欢使用物理中间件解决方案(PhysX、Bullet 等)，因为它们更加成熟、经过良好测试，并且从长远来看通常会简化开发。不建议编写自己的物理实现，除非是在学习如何去做的情况下。