C# 的托管物理引擎与非托管物理引擎
有人尝试过 BEPU 物理引擎吗？ http://bepuphysicals.codeplex.com/
这是一个用 C# 编写的完全托管的物理引擎......我知道它主要用于 XNA（XBOX 和 WP7 项目），因为不允许使用非托管代码。
但我想知道的是，在 Windows 环境中，完全托管的物理引擎与 P/Invoked 引擎（例如 tao.ODE）相比如何（在性能方面） ）？
换句话说，在实际项目中，哪种方法会产生更多开销，完全托管代码或围绕非托管引擎（如 ODE 或 PhysX）的 P/Invoke Wrapper？
anyone tried BEPU Physic Engine ?
http://bepuphysics.codeplex.com/
It's a fully managed physic engine written in C# ... I know it mostly used for XNA ( XBOX and WP7 Projects ) Because Unmanaged Codes are not Allowed.
But what I want to know is how a fully Managed Physic Engine is compared to a P/Invoked One ( For example tao.ODE ) in Windows Environment ( in term of performance ) ?
In other words which method makes more overhead, fully managed code or P/Invoke Wrapper around unmanaged Engines like ODE or PhysX in a Real Project?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我无法评论特定的物理引擎，但是我可以提供一些编写高性能代码（非托管和托管）的经验。
几年前，我开发了一款用 Delphi 编写并移植到 .NET 的模拟软件（我可能会说在我到来之前）。它是用于质谱仪模拟的纯托管代码和计算离子轨迹。该代码涉及数值积分、微分、N 体静电荷计算，因此肯定是在测试 CPU。
通过各种尝试寻找最高性能的实验，我发现某些 C++ 版本的模拟例程可能会被优化良好的 C# 代码击败。
我所说的良好优化是指减少新运算符（对象的重用）、缓存、对象池、尽可能使用结构、尽可能减少方法调用、将方法调用移至静态 /
密封在可能的情况下，尽量减少传递给方法的参数数量，在 x64 版本中编译，与调试器分离。完成此操作后，为了真正使用 C++ 击败 CLR，我必须求助于低级技术，例如 SSE/SSE2 和内联汇编器。好吧，我承认，C# 和托管语言无法与经验丰富的人手工优化的 C++ 代码相媲美，但我在这两个平台上都看到过优化不佳的代码。当 C# 代码速度缓慢时，很容易将责任归咎于 CLR，但当开发人员随意使用 new 运算符时，我发现很奇怪，他们对 GC 运行如此频繁感到惊讶。 C++ 中的
new和delete也会对性能造成影响，因此不要指望 C++ 编译只会让事情变得更快。回到您的特定引擎 - 您当然必须自己进行一些测试和性能分析。关于平台调用，当跨托管/非托管边界编组指针和结构时，它确实会产生称为 thunking 的性能影响。纯托管代码不会有这个，但它也会错过可以用 C++ 编码的优化，例如低级内存复制、SSE/SSE2 扩展等。
最后我要说的是，对于一个非常强大且快速的托管->平台调用库的示例，请看一下 SlimDX。好吧，与本机代码和 DirectX 相比，您的性能会受到影响（一些消息来源称约为 5%），但为了提高 C# 开发的生产力优势，我认为这是值得的！
I cannot comment on the specific physics engines, however I can offer some experience in writing high performance code (both unmanaged and managed).
A few years ago I worked on a piece of simulation software written in Delphi and ported to .NET (before my arrival I might say). It was pure managed code and computed ion-trajectories for mass spectrometer simulations. The code involved numerical integration, differentiation, N-body electrostatic charge calculations so was certainly testing the CPU.
I found through various experiments trying to find the highest performance that some C++ versions of the simulation routines could be beaten by well optimized C# code.
By well optimized I mean reduction of new operators (re-use of objects), caching, object pooling, use of structs where possible, minimizing method calls where possible, moving method calls to
static/sealedwhere possible, minimize number of parameters passed to methods, compile in release, x64, detached from debugger. Once I had done this, to actually beat the CLR using C++ I had to resort to low level techniques such as SSE/SSE2 and inline assembler.Ok, I'll admit, C# and managed languages are no match for hand-optimized C++ code in experienced hands, but I've seen poorly optimized code on both platforms. It's easy to blame the CLR when C# code is slow but when developers are using the
newoperator at will I find it odd they get surprised when the GC is run so frequently.newanddeletein C++ also imposes a performance hit so don't expect C++ compilation to just make things faster.Back to your specific engine - you will have to of course do some testing and performance analysis yourself. Regarding platform invoke, it does incur a performance hit known as thunking when pointers and structs are marshalled across the managed/unmanaged boundary. Pure managed code will not have this but also it will miss out on optimisations such as low level memory copy, SSE/SSE2 extensions etc... that can be coded in C++.
Finally I will say that for an example of managed->Platform invoke library that is extremely powerful and fast, take a look at SlimDX. Ok you're going to get a performance hit over native code and DirectX (some sources say ~5%) but for the productivity benefits of developing in C# I'd say its worth it!
两者都很糟糕 - 如今获得真正高性能的唯一方法不是“处理器代码”中的“非托管”，而是“在显卡上运行”中的“非托管”。
Both suck - the only way to get realy high performance these days is not "unmanaged" as in "processor code" but "unmanaged" as in "running on the graphics card".