誰かがBEPUPhysicEngineを試しましたか？ http://bepuphysics.codeplex.com/
これは、C＃で記述されたフルマネージドの物理エンジンです...アンマネージドコードは許可されていないため、主にXNA（XBOXおよびWP7プロジェクト）で使用されていることを私は知っています。
しかし、私が知りたいのは、完全に管理された物理エンジンを、 Windows環境でP / Invokedエンジン（たとえば、tao.ODE）と比較する方法です（パフォーマンスの観点から）？
言い換えると、実際のプロジェクトでODEやPhysXなどのアンマネージエンジンのオーバーヘッド、フルマネージコード、またはP / Invoke Wrapperを増やす方法はどれですか？
特定の物理エンジンについてコメントすることはできませんが、高性能コード (アンマネージとマネージの両方) を作成する経験を提供できます。
数年前、私は Delphi で記述され、.NET に移植されたシミュレーション ソフトウェアの一部に取り組みました (私が到着する前に言ったかもしれませんが)。それは純粋に管理されたコードであり、質量分析計シミュレーション用の計算されたイオン軌道でした。コードには数値積分、微分、N 体静電荷計算が含まれていたため、CPU をテストしていたことは確かです。
最高のパフォーマンスを見つけようとしてさまざまな実験を行った結果、シミュレーション ルーチンの一部の C++ バージョンは、適切に最適化された C# コードによって打ち負かされる可能性があることがわかりました。
最適化とは、新しい演算子の削減 (オブジェクトの再利用)、キャッシング、オブジェクト プーリング、可能な場合は構造体の使用、可能な場合はメソッド呼び出しを最小限に抑えること、可能な場合はメソッド呼び出しをstatic/sealedに移動すること、メソッドに渡されるパラメーターの数を最小限に抑えることを意味します。デバッガーから切り離されたリリース、x64 でコンパイルします。これを行った後、実際に C++ を使用して CLR を打ち負かすには、SSE/SSE2 やインライン アセンブラーなどの低レベルの手法に頼る必要がありました。
確かに、C# とマネージ言語は、経験豊富な人の手で最適化された C++ コードに匹敵するものではありませんが、両方のプラットフォームで最適化が不十分なコードを見てきました。C# コードが遅いと CLR のせいにするのは簡単ですが、開発者がnew演算子を自由に使用している場合、GC が頻繁に実行されると驚かれるのは奇妙だと思います。newまたdelete、C++ でもパフォーマンス ヒットが発生するため、C++ のコンパイルが単に高速化するとは思わないでください。
特定のエンジンに戻ります。もちろん、テストとパフォーマンス分析を自分で行う必要があります。プラットフォームの呼び出しに関しては、ポインターと構造体がマネージド/アンマネージド境界を越えてマーシャリングされると、サンキングと呼ばれるパフォーマンス ヒットが発生します。純粋なマネージド コードにはこれがありませんが、C++ でコーディングできる低レベルのメモリ コピー、SSE/SSE2 拡張機能などの最適化も見逃されます。
最後に、非常に強力で高速なマネージド -> プラットフォーム呼び出しライブラリの例として、SlimDX を見てみましょう。ネイティブ コードと DirectX よりもパフォーマンスが向上します (一部の情報源によると ~5%) が、C# で開発することの生産性の利点については、それだけの価値があると思います!
しかし、私が知りたいのは、完全に管理された物理エンジンが、Windows 環境で (パフォーマンスに関して) P/Invoked One (tao.ODE など) とどのように比較されるかです。
どちらも最悪です。最近、本当に高いパフォーマンスを得る唯一の方法は、「プロセッサ コード」のように「管理されていない」のではなく、「グラフィックス カードで実行する」のように「管理されていない」ことです。