Async sample pack

Async sample pack が公開され、ネイティブ同時実行ブログ(英語)にその解説が掲載されました。以下の非同期サンプルが含まれています。 ファイルアクセス チャンク内のファイルコピー ファイル圧縮 マージソート 画像転送 NQeens

0

Daniel Moth の C++ AMP プレゼン

Daniel Moth の C++ AMP のプレゼンとデモが彼のブログで公開されています。Direct3DのN体問題をC++ AMPで高速化したデモのビデオも含まれています。 C++ AMP概要スライドも彼のブログからダウンロードできます。

0

MSDN マガジン:.NET アプリケーションの並列処理についての過去、現在、未来

現在 MSDN マガジンの日本語化は、機械翻訳のものと(人的)翻訳のものがありますが、Stephen Toubによるこの「.NET アプリケーションの並列処理についての過去、現在、未来」は幸いなことに(人的)翻訳でした。 この記事では、.NET 4 で利用可能になった Task などの並列・同時実行ライブラリーを手短にまとめるとともに、今後の拡張について述べています。それは主に async 注釈や BufferBlock のような言語サポートを含む、非同期処理の拡張です。 メニーコアを活用する .NET の並列・同時実行あるいは非同期に興味のある方は是非お読みください。

0

C++ AMP (Accelerated Massive Parallelism)

先週開催された AMD の Fusion カンファレンスで、Daniel Moth が C++ AMP (Accelerated Massive Parallelism) のデモを行いました。C++ AMP とは、簡単に言うと、C++ で GPU の並列プログラミングを実装するものです。 ビデオ スライド Daniel Moth のブログから引用すると、C++ AMP とは… 開発者の生産性やソリューションの移植性を犠牲にすることなく、ヘテロ(つまり CPU と GPU)なハードウェア プログラミングの壁を低くし、その性能をメインストリームに提供する。 今日の大規模並列ハードウェア(つまりGPU と CPU)の使用を援助するだけではなく、コードへの投資を、将来に備えたデザインとして堅固なものにもする。 Visual Studio の一部であり、別のコンパイラーや別の構文を学ぶ必要はない。 現在の C++ であり、C やその他の派生言語ではない。 Visual Studio vNext と完全に統合・サポート。編集・ビルド・デバッグ・プロファイルなど Visual Studio  の他のすべての機能が C++ AMP とともに動作する。 既存の同時実行名前空間の一部としてSTL に似たライブラリを提供し、amp.h ヘッダーファイルを提供する。 並列化が顕著な形として、ヘテロなハードウェア上で巨大な多次元データで非常に容易に動作する。 唯一のコア…

2

書籍:.NET 開発テクノロジー入門 VS2010対応版

昨年出版された「.NET 開発テクノロジ入門」の .NET 4 バージョン「.NET 開発テクノロジー入門 VS2010対応版」が出版されました。今回私は第6章「並列プログラミング」を担当し、TPL(タスク並列ライブラリー)と同時実行ランタイム(スレッドプール)について解説しました。 第1章:.NET Framework 4 による最新のアプリケーション開発(はじめに) 第2章:Web アプリケーションの開発(ASP.NET) 第3章:リッチクライアントアプリケーション開発(WPF/Silverlight) 第4章:サービス開発 / 分散テクノロジー(WCF) 第5章:データアクセス技術(ASP.NET / LINQ) 第6章:並列プログラミング

3

書籍:Parellel プログラミング in .NET Framework 4

今日本屋さんをうろうろしていて見つけました。Parallel プログラミング  in .NET Framework 4 (ISBN 978-4877832483) 。この本では TPL(タスク並列ライブラリー)を使った並列プログラミングをC#で解説しており、サウンドや画像のサンプルコードがCDで同梱されています。

0

書籍 Parallel Programming with Microsoft .NET

O’Reilly から「Parallel Programming with Microsoft .NET ~Design Patterns for Decomposition and Coordination on Multicore Architectures~」が出版されました(たしか昨年、Microsoft Press の出版事業は O’Reilly に移行されました。) 執筆陣は、TPLなど .NET 並列ライブラリーのプログラム マネージャや開発者などです。

0

並列プログラミングの落とし穴⑤スタベーション

スタベーション(starvation)とは「飢餓」という意味です。 複数のタスクが同時実行しているとき、あるタスクがスケジューリングされない、あるいはリソースにアクセスできない時間が長期に続くことです。結果的にそのタスクは飢餓状態になります。 並列プログラミングにおけるスタベーションの例としてよく出てくるのが、ダイクストラが提示した「食事する哲学者の問題」です。この問題は、5人の哲学者が円卓に座って「食事」(スパゲティ)と「思索」を続けるとき、食事には間にあるフォーク(「箸」と書いてあることもある)が2本必要という制約の下で、デッドロックもスタベーションも起こさないようにするにはどうすればよいかという問題です。もともと「飢餓」という言葉もこの「食事」から来ているようです。 デッドロックに比べスタベーションはあまり発生しないので、開発時に問題を発見するのが難しいです。 「並列プログラム サンプル for .NET 4」と「並行ランタイム&PPL サンプル for Win32」に「食事する哲学者」のサンプルコード(DiningPhilosophers)があるので参照してください。また、MSDN Magazine June 2009でも VS2010 の C++ Asynchronous Agents Libraryによる解決方法が解説されています。

0

並列プログラミングの落とし穴④デッドロック

これまで紹介してきた並列プログラミングの落とし穴のいくつかは、ロックを使えば回避できます。①でも次のようなロックによる問題解決(および副作用)を紹介しました。         internal static int GetNext()         {             return Interlocked.Increment(ref s_curr);         } ロックとは、ある範囲の処理やオブジェクト・メモリーへのアクセスを同時には実行できないようにするテクニックであり、「クリティカル セクション」とか「ミューテックス」とか「セマフォ」とか「モニター」などという、同じ目的の微妙に意味や使い方の異なるテクニックがあります。ここではまとめて「ロック」と呼び、個別のテクニックの紹介はしません。     しかしロックにはいくつかの副作用があります。ロックが引き起こす最も厄介な問題がデッドロックです。デッドロックは2つのタスクが2つのオブジェクトをロックしようとするときに発生します。タスクAがオブジェクトaをロックしてからオブジェクトbをロックし、同時にタスクBがオブジェクトbをロックしてからオブジェクトaをロックしようとすると、両方のタスクが他方のタスクのロック解放を待つため、デッドロックが発生します。     銀行口座の作成・入金・引き出し・振込ができる、ロックを使った次のコードを見てみましょう。BankAccountクラスにはコンストラクターと、入金メソッドDepositと、引き出しメソッドWithdrawと、振込メソッドTransferがあります。Mainプログラムでは、それぞれ100万円で2つの口座を作成し、2つのタスクで一方の口座から他方の口座へ、口座aは口座bに1,000円を、口座bは口座aに100円を、振り込み続けます。どちらかの口座の預金残高が振込額より少なくなると、例外が発生して終わります。     class Program     {         static void Main(string[] args)         {             BankAccount a = new BankAccount(0, 1000000);             BankAccount b = new BankAccount(1, 1000000);             Task A = Task.Factory.StartNew(() =>            …

0

並列プログラミングの落とし穴③コード順序の入れ替え

最適化のためにプロセッサーは、実行中に命令の順序を入れ替えることがあり、並列プログラミングではこれも問題を引き起こします。 次のコードでは、全ての変数を0で初期化し、タスクAではs_xに「1」を代入してからs_yaにs_yを代入します。タスクBではs_yに「1」を代入してからs_xaにs_xを代入します。タスクAとタスクBを同時実行させますが、タスクAが先に実行されればs_xaが「1」のはずですし、タスクBが先に実行されればs_yaが「1」のはずです。また、同時に実行されればどちらも「1」となります。 AとBのタスクが終了したあとで、両方が「0」になっていることはありえないように思われます。 class Program     {         internal static volatile int s_x;         internal static volatile int s_xa;         internal static volatile int s_y;         internal static volatile int s_ya;         static void Main(string[] args)         {             while (true)             {                 s_x = 0;                 s_xa = 0;                 s_y = 0;…

0