Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à マルチコア時代の並列プログラミング
Plus de Akihiko Matuura
マルチコア時代の並列プログラミング
- 2. 自己紹介：社外のボク 2 •翻訳本の監修メンバー • 『C++の設計と進化』← Amazon 1位！ • 『ストラウストラップのプログラミング入門』 • 雑誌記事『STL.NET』 •sapporo.cpp/boostjp • 『プログラミングの魔法少女』 • https://sites.google.com/site/sapporocpp/linguamagi 13年9月22日日曜日
- 7. 並列プログラミング 「並列プログラミングって、マルチス レッドで動いて、共有オブジェクトは 排他する、アレですよね？」 6 あちゃー、地球の重力に縛られたオ ールドタイプだわ！ 13年9月22日日曜日
- 8. 並列プログラミングとは •ムーアの法則の終焉（The Free Lunch is Over） •マルチコア時代の到来 7 シングルスレッドで動作するプログラムはこれ以 上早くならない。 マルチコアによる真の並列処理を指す。極力排他 しない・待たせないことが重要。 13年9月22日日曜日
- 10. Singleton 9 public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } 例：マルチスレッド環境で遅延初期化なシングルトン 13年9月22日日曜日
- 11. Singleton 9 public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } ほとんどの場合、無駄に排他される 例：マルチスレッド環境で遅延初期化なシングルトン 13年9月22日日曜日
- 12. Double Checked Locking （以下DCL） 10 public static Singleton getInstance() { if (instance == null) // Check 1 { synchronized(Singleton.class) { if (instance == null) // Check 2 instance = new Singleton(); } } return instance; } 13年9月22日日曜日
- 13. DCLどーよ？ • DCLとは、「ロック→条件判定」というロジックを 「条件判定→ロック→(再度)条件判定」と書き換える イディオム。 • 主に遅延初期化などの処理においてロックのオーバー ヘッドを減らすために用いられた。 • ところが！ DCLはコンパイラやCPUによるリオーダ ーの影響等により正しく動作しない場合が あることがわかったため、今ではアンチパターンと 呼ばれることすらある。 • ただし、現代において、DCLは正しく実装すれば有用であ る。→ 今回の範囲外 11 13年9月22日日曜日
- 15. 並列プログラミングのキモ • スレッドやロックが主役ではない • 「状態（state）」が問題 • 複数スレッドから同時アクセスしてしまう。 • 副作用に依存する逐次処理もまた状態依存 • これらをスレッドセーフにする必要がある （スレッドセーフでない状態：データレース） 13 13年9月22日日曜日
- 16. アトミック(Atomic) • 不可分のこと • これ以上処理を分割することができない • あるいは分割出来ないようにした単位 • アトミックでなければ他のスレッドに割り込まれ、スレッ ドセーフを保証できない。 • アトミックでない例 14 ++count; // 「Read Modify Write」 long long value = 100; // 64bit変数 value = 0; // 32bitレジスタ２つによる実装が許されている 13年9月22日日曜日
- 17. リオーダー問題(reoder) 15 シングルスレッドで動く分にはプログラムは書いてある とおりに動く（ように見える）。 int x,y; // グローバルに x = 1; y = 2; // ここに来とき y==2 && x==1 である ここには一貫性セマンティクスがある あたりまえじゃん！ 13年9月22日日曜日
- 18. 16 リオーダー問題(reoder) // スレッド（１） x = 1; y = 2; // ここに来とき y==2 && x==1 である // スレッド（２） y==2 なら、必ず x==1 か？ 13年9月22日日曜日
- 19. 16 リオーダー問題(reoder) // スレッド（１） x = 1; y = 2; // ここに来とき y==2 && x==1 である // スレッド（２） y==2 なら、必ず x==1 か？ そんな保証はどこにもない → リオーダーされるから 13年9月22日日曜日
- 20. リオーダーって？ • プ ロ グ ラ ム 実 行 速 度 の 向 上 な ど の 目 的 で 実 行 順 序 を 入 れ 替 え る 最 適 化 手 法 の 一 つ x = 1; y = 2; • あるスレッドにとって問題ないなら順番を入れ替えちゃうか も • コンパイラがプログラムコードを機械語に変換するとき • CPUが機械語のコードを実際に実行するとき • キ ャ ッ シ ュ メ モ リ の 影 響 な ど を 考 慮 し て 命 令 の 実 行 順 序 を 入 れ 替 え る！ 17 13年9月22日日曜日
- 21. 可視性 (Memory Visibility) 18 // スレッド１ read_file(buffer); // でかいデータよむ read_flag = true; // スレッド２ while( ! read_flag ); // readが終わるの待つ write_console(buffer); // 読み取った内容をコンソールに bool read_flag = false; これちゃんと動くか？ 13年9月22日日曜日
- 22. 可視性 (Memory Visibility) 18 // スレッド１ read_file(buffer); // でかいデータよむ read_flag = true; // スレッド２ while( ! read_flag ); // readが終わるの待つ write_console(buffer); // 読み取った内容をコンソールに bool read_flag = false; これちゃんと動くか？ そんな保証はどこにもない 13年9月22日日曜日
- 23. 可視性 (Memory Visibility) 18 // スレッド１ read_file(buffer); // でかいデータよむ read_flag = true; // スレッド２ while( ! read_flag ); // readが終わるの待つ write_console(buffer); // 読み取った内容をコンソールに bool read_flag = false; これちゃんと動くか？ そんな保証はどこにもない それどころかスレッド２は永遠にwhile()するかも 13年9月22日日曜日
- 24. 可視性って •コンパイラやCPUが、キャッシュメモ リの利用を最適化する。 •そのため、あるスレッドでのメモリの 見え方が、別のスレッドで同じように 見えるとは限らない。 19 13年9月22日日曜日
- 34. DCL 25 public static Singleton getInstance() { if (instance == null) // Check 1 { synchronized(Singleton.class) { if (instance == null) // Check 2 instance = new Singleton(); } } return instance; } 13年9月22日日曜日
- 35. DCLの問題 26 mem = allocate(); instance = mem; // (*) ctorSingleton(instance); instance = new Singleton(); ↑これ、いくつかのJITコンパイラは次の コードを生成する。 (*)の時点で、instanceは未初期化の領域 を指す。→ 負け 13年9月22日日曜日
- 36. じゃあこれなら？ 27 tmp = new Singleton(); instance = tmp; 13年9月22日日曜日
- 37. じゃあこれなら？ 27 tmp = new Singleton(); instance = tmp; 結局だめ。コンパイラはtmpなんて一時変数無 しに最適化するかも知んない。 13年9月22日日曜日
- 38. じゃあこれなら？ 27 tmp = new Singleton(); instance = tmp; 結局だめ。コンパイラはtmpなんて一時変数無 しに最適化するかも知んない。 instance = new Singleton(); // 負け 13年9月22日日曜日
- 39. これならいいべ？ 28 mem = allocate(); // 1 ctorSingleton(mem); // 2 instance = mem; // 3 あるJITコンパイラが以下のコードを生成 するとしたら？ 13年9月22日日曜日
- 40. これならいいべ？ 28 mem = allocate(); // 1 ctorSingleton(mem); // 2 instance = mem; // 3 あるJITコンパイラが以下のコードを生成 するとしたら？ だめ。リオーダーされるかも。→ 負け 13年9月22日日曜日
- 41. これならいいべ？ 28 mem = allocate(); // 1 ctorSingleton(mem); // 2 instance = mem; // 3 あるJITコンパイラが以下のコードを生成 するとしたら？ だめ。リオーダーされるかも。→ 負け mem = allocate(); // 1 instance = mem; // 3 ctorSingleton(mem); // 2 13年9月22日日曜日
- 42. ひとまず、まとめ • マルチコアの世界を正しく理解する必要があ る。 • 思い込みいくない（あるスレッドの逐次性が他のスレッ ドからも同じように見えるなどと考えてはいけない）。 • 並列プログラミングをサポートする標準API やライブラリを使う。 • 心配なら普通にロックモデルを採用しよう。 29 13年9月22日日曜日
- 43. Java/C++ • リオーダーを細かく制御するメモリバリア API • アトミック性を提供するデータ型やキーワ ード • JavaやC++では様々なAPIが提供される。 • ゼロ・オーバーヘッド原則のC++はとんでもないことやってます（超むず） 30 13年9月22日日曜日
- 44. 様々な並列道具 •Java concurrentパッケージ •Java 8 Fork/Join Framework • concurrentパッケージ 拡張。Parallel系、lambda •C++11 Atomic operations library •C#4.0 Parallel.For 31 13年9月22日日曜日
- 45. 並列いろいろ • Lock-freeアルゴリズム・データ構造 • SIMD (Single Instruction Multiple Data) • GPGPU • アクターモデル（ScalaのActor、Cocoaの Operation Queue） • OpenMP、PPL（Parallel Pattern Library） • STM(Software Transactional Memory) 32 13年9月22日日曜日
- 46. 最後に、関数型言語 • そもそもの問題は「状態」だ。 • 状態（副作用）を持たない関数型言語は、 並列プログラミングとの相性がよい。 • Haskell、Erlang、Ocaml、Scala、F#、 • C#、C++、... 33 13年9月22日日曜日
- 47. 最後に、関数型言語 • そもそもの問題は「状態」だ。 • 状態（副作用）を持たない関数型言語は、 並列プログラミングとの相性がよい。 • Haskell、Erlang、Ocaml、Scala、F#、 • C#、C++、... 33 マルチコアな現代、 関数型言語が注目されている！ 13年9月22日日曜日