最近のマルチコアおよびマルチプロセッシングハードウェアの非常に重要性を考慮して、人々が現在どのように並列コードを実際に書いているのかを把握しようとしています。私にとっては、Linuxでネイティブであり、Windowsで使用可能なpthread（POSIXスレッド）が主流のパラダイムのようです。 HPCの人々はOpenMPやMPIを使う傾向がありますが、StackOverflowにはこれらの多くはありません。それとも、移植性のある標準ではなく、Javaスレッド、WindowsスレッドAPIなどに頼っていますか。あなたの意見では、並列プログラミングを行うための推奨される方法は何ですか？
それとも、Erlang、CUDA、RapidMind、CodePlay、Oz、あるいは親愛なるOccamのようなもっとエキゾチックなものを使っていますか？
明確化：私は、移植性が非常に高く、Linux、さまざまなUNIX、さまざまなホストアーキテクチャなどのプラットフォームに適用可能なソリューションを探しています。 Windowsはサポートするのに適している稀なケースです。そのため、C#と.netは非常に狭すぎます。CLRはクールなテクノロジですが、JVM、Python、Erlang、またはその他の移植可能な言語と同じくらい普及するように、Linuxホスト用にリリースしてください。
C ++またはJVMベース：JVMはパフォーマンスを隠す傾向があるので、おそらくC ++です。
MPI：HPCの人々でさえそれを使いにくいツールだと思っていることに私は同意するでしょう - しかし128000プロセッサ上で実行するためには、map / reduceが適用されない問題に対する唯一のスケーラブルな解決策です。ただし、メッセージパッシングは、ローカルメモリ/ AMP、共有メモリ/ SMP、分散ランタイム環境に非常に適していると思われる唯一のプログラミングスタイルであるため、非常に優雅です。
興味深い新しい候補はCAPI。しかし、私はまだ誰かがそれについて実際的な経験をする時間があるとは思いません。
全体的に見て、私が知らなかった興味深いMicrosoftプロジェクトがたくさんあり、Windows APIまたはpthreadが実際に最も一般的な実装であるという状況があるようです。
MPIは、ほとんどの人が見かけほど難しくありません。現在、私はマルチパラダイムアプローチが並列分散アプリケーションに最も適していると思います。ノード間の通信と同期にMPIを使用し、より詳細な並列化にはOpenMPまたはPTスレッドを使用します。各マシンにはMPIを、各コアにはOpenMPまたはPThreadを考えてください。近い将来、コアごとに新しいMPI Procを生成するよりも、これは少し改善されているように見えます。
おそらく今のところデュアルコアやクアッドコアの場合、マシン上の各コアにprocを生成してもそれほどのオーバーヘッドはありませんが、キャッシュとメモリがそれほど拡張されていないマシンあたりのコア数が増えるにつれて、共有メモリモデルを使用する方が適切です。
お勧めしますOpenMP。 MicrosoftはそれをVisual C ++ 2005コンパイラに組み込んでサポートしているので、/ ompディレクティブを使用してコンパイルする以外に何もする必要はありません。
使い方は簡単ですが、明らかにあなたのためにすべてを行うわけではありませんが、その後は何もしません。私は自分でロールバックする傾向があるより複雑なもののために、一般的に何の面倒もなくループのための並列実行にそれを使用します（例えば、私はカット、ペースト、そして修正の前からコードを持っています）。
あなたは試すことができますシルク++これはよさそうだし、電子書籍も「マルチコアソフトウェア革命を乗り切る方法」。
これらの種類のシステムは両方ともシリアルコードを並列化しようとします - すなわちforループを取り、できるだけ簡単にすべてのコアでそれを同時に実行します。それらは汎用のスレッドライブラリではありません。 （例：研究論文（pdf）は、openMPで実装されたさまざまな種類のスレッドプールのパフォーマンスを説明し、2つの新しいオペレーション、すなわちyieldとsleepを追加する必要があることを提案しました。私は彼らがOpenMPのポイントを少し欠いていると思う）
OpenMPについて述べたように、C#や.NETではなく、ネイティブc ++について話していると思います。
また、HPCの人々（私がこの種のドメインの専門家であると思う人）がOpenMPまたはMPIを使用しているように思われる場合、これがあなたが使用すべきものであり、SOの読者ではありません！
パラレルFXライブラリ（PFX） - 将来の.NET Frameworkの改訂版に含めるために、Microsoft ResearchとMicrosoftのCLRチームとの共同作業によって開発されているマネージド並行処理ライブラリ。それは2つの部分から構成されています：パラレルLINQ（PLINQ）とタスクパラレルライブラリ（TPL）。それはまた、一組のコーディネーションデータ構造（ＣＤＳ） - 同時タスクの実行を同期させ調整するために使用される一組のデータ構造からなる。この図書館は2007年11月29日にCTPとして公開され、2007年12月と2008年6月に再び更新されました。
あまり経験がないですが…
ここでの答えは「実際に使う」に対する統計的に代表的な答えにはならないことに注意してください。すでに私はいくつかの "X is nice"という答えを見ました。
私は個人的に多くのプロジェクトでWindowsスレッドを使用しました。私が広く使用している他のAPIはpthreadsです。 HPCの面では、MPIはまだそれを使用している人々によって真剣に取られています<subjective>私は違います - それはC ++の優雅さとJavascriptの性能を兼ね備えています。まともな代替手段がないのでそれは生き残ります。一方ではNUMAマシンを密結合し、もう一方ではGoogleスタイルのマップリダクションを実行することはできません。</subjective>
環境によって大きく異なります。
palin old CではPOSIXを上回るものは何もありません。
C ++の場合、BOOST.ORGの無料の非常に優れたスレッドライブラリがあります。
JavaはネイティブのJavaスレッドを使うだけです。
アプリケーションをクライアントとサーバーのプロセスに分割したり、非同期メッセージングを使用して通信したりするなど、スレッド化以外の並列処理を実現する他の方法を検討することもできます。適切に行われると、これは何十ものサーバー上で何千ものユーザーに拡大することができます。
Windows MFC、Gnome、またはQtウィンドウ環境を使用している場合は、自動的にマルチスレッド環境になることも思い出してください。 Apache ISSまたはJ2EEを使用している場合、アプリケーションはすでにマルチスレッドマルチプロセス環境内で実行されています。
私が書いた並行プログラムのほとんどは、ありますかこれは、言語内でネイティブに並列処理を完全にサポートしています。これの良い利点の1つは、あなたの並列コードがAdaコンパイラを持つどんなシステムにも移植可能であるということです。特別なライブラリは必要ありません。
PLINQの場合は+1
Win32スレッド、スレッドプールとファイバー、同期オブジェクト
私は並行性リンクのブログを保守しています。このブログは時間の経過とともにこれらの多くをカバーしてきました（そしてこれからも続けていきます）。
私は今のところJavaだけを知っています、そこでマルチスレッドのサポートは私のためにうまくいきました..
私は主にその単純さ、移植性、そして柔軟性のためにOpenMPを多用しました。それは万能のC ++ / Cliでさえも複数の言語をサポートします:)
私はMPIを使っていてとても気に入っています。それはあなたにメモリ階層について考えることを強制します、しかし私の経験では、とにかくそのようなことについて考えることは高性能にとって重要です。多くの場合、MPIは主にドメイン固有の並列オブジェクトの背後に隠れていることがあります（たとえば、線形方程式と非線形方程式を解くためのPETSc）。
pycuda ... 25000のアクティブスレッドのようなものはありません:) [ワープはスコアボードでスケジュールされました]。 cuda 2はストリームサポートを持っているので、どんなstreamitがもたらすのか私にはわかりません。 CUDA Matlabの拡張機能は見栄えがよく、冥王星そしてMITから来るPetaBricks。
他のものと同じくらい、pythonのスレッド化は欠けています。 MPIなどは複雑であり、私はクラスタを持っていませんが、私は彼らが彼らのために構築されたものを達成すると思います。スレッドアパートメントに入る前にC#プログラミングをやめました（おそらく良いことです）。
そうではありません平行それ自体は分散モデルではありませんが、Clojureを使用してJVM上で高度に並行したコードを書くことができます。その後、あなたはたくさんのJavaライブラリを利用できるようになります。あなたはclojureの上にあなた自身の並列アルゴを実装しなければならないでしょうが、それは比較的簡単なはずです。繰り返さないまだ分散モデルがあります。
glibcライブラリからのgthreadshttp://library.gnome.org/devel/glib/stable/glib-Threads.htmlpthreadまでコンパイルするので、パフォーマンスが低下することはありません。また、非常に強力なスレッドプール、およびスレッド間のメッセージキューも提供されます。私は何度かうまくそれらを使用しました、そして利用可能な機能にとても満足していました。
私はopen clを使っています。mpiと比べるとかなり使いやすいと思います。以前は並列分散コンピューティングコースの要件としてmpiを使っていましたが、手作業が多すぎるのではないかと思います。 CUDAはopen clに非常に似ていますが、問題はCUDAがnvidia製品のためだけであるということです。