Windows 用のデータマイニング パッケージを開発する予定です。プログラムコア/計算エンジンはF#で開発され、GUI関連/DBバインディングなどはC#とF#で行われます。
ただし、モデルの実装についてはまだ決定していません。高いパフォーマンスが必要なため、ここではマネージ コードを使用できない可能性があります (異論はありますか?)。問題は、モデルを FORTRAN で開発するのが合理的か、それとも C (または C++) にこだわるべきかということです。適切なモデルのために、ある時点で OpenCL を使用することを検討しています。これらの状況で、マネージド コード -> FORTRAN -> C -> OpenCL 呼び出しから移動する必要があるのはおかしいと感じています。
推奨事項はありますか？
F# は、ジャストインタイム コンパイラを備えた CLR にコンパイルされます。これは、強く型付けされた ML の方言であり、そのタイプのアーキテクチャに適した優れた最適化をすべて可能にします。これは、おそらく F# から妥当なパフォーマンスが得られることを意味します。比較のために、コードを OCaml (IIRC はネイティブ コードにコンパイル) に移植してみて、それが実質的な違いを生むかどうかを確認することもできます。
本当に遅すぎる場合は、そのスケーリング ハードウェアがどこまで到達するかを確認してください。最新の PC やサーバーで利用できるパフォーマンスでは、真にブロブディナジアンなデータ セットを扱っていない限り、特殊なものを使用する必要はないように思われます。データ セットが小さいユーザーは、通常の PC で問題ない可能性があります。
ワークステーションは、おそらく標準的なデスクトップ PC よりも 1 桁多くの容量を提供します。HP Z800やXW9400などのハイエンド ワークステーション(他のいくつかのメーカーから同様のキットが入手可能です) は、2 つの 4 または 6 コアの CPU チップ、数十ギガバイトの RAM (場合によっては最大 192GB) を使用でき、高パフォーマンスのためのさまざまなオプションがあります。 -SAS ディスク、外部ディスク アレイ、SSD などの高速 I/O。 このタイプのハードウェアは高価ですが、大量のプログラマーの時間よりも安価な場合があります。既存のデスクトップ サポート インフラストラクチャは、この種のキットに対応できるはずです。最も可能性の高い問題は、64 ビット O/S で 32 ビット ソフトウェアを実行する際の互換性の問題です。この場合、互換性の問題を回避するために、VM や KVM スイッチなどのさまざまなオプションがあります。
次のステップは、4 または 8 ソケット サーバーです。ごく普通の wintel サーバーは、Wintel プラットフォームから移動することなく、最大 8 ソケット (32 ～ 48 コア) とおそらく 512 GB の RAM に対応します。これにより、選択したプラットフォーム内で、エキゾチックなものに移動する前に、かなり幅広いオプションが提供されます1。
最後に、F# ですばやく実行できない場合は、F# プロトタイプを検証し、F# プロトタイプをコントロールとして使用して C 実装をビルドします。それでも十分に速くない場合は、問題があります。
プラットフォームに適した方法でアプリケーションを構築できる場合は、よりエキゾチックなプラットフォームを検討できます。アプリケーションで何が機能するかに応じて、クラスター、クラウド プロバイダーでホストしたり、GPU、 Cell プロセッサ、またはFPGA でコア エンジンを構築したりできる場合があります。 ただし、これを行うと、サポートの問題を引き起こす可能性のある (かなりの) 追加コストとエキゾチックな依存関係が発生します。おそらく、プラットフォームのプログラミング方法を知っているサードパーティのコンサルタントも連れてくる必要があります.
結局のところ、最善のアドバイスは次のとおりです。それを吸って見てください。F# に慣れている場合は、アプリケーションのプロトタイプをかなり迅速に作成できるはずです。実際に問題になるという明確な兆候が得られるまでは、実行速度を確認し、パフォーマンスについてあまり心配しないでください。時期尚早の最適化は、約 97% の確率で諸悪の根源であると Knuth が述べたことを思い出してください。問題がないか天候に注意を払い、パフォーマンスが本当に問題を引き起こすと思われる場合は、戦略を再評価してください。
編集：パッケージ化されたアプリケーションを作成したい場合は、おそらくそうでない場合よりもパフォーマンスに敏感になるでしょう。この場合、特注システムよりも早くパフォーマンスが問題になる可能性があります。ただし、これは基本的な 'suck it and see' の原則には影響しません。
まだ最適化を気にしないことをお勧めします。最初に動作するプロトタイプを取得してから、計算時間が費やされている場所を見つけます。必要に応じて、おそらく最大のボトルネックを C または Fortran に移すことができます。その後、それがどれほどの違いをもたらすかを確認してください。
彼らが言うように、多くの場合、計算の 90% がコードの 10% に費やされます。