ハードウェアの観点からの並列化の進化

作者 Srini Penchikala , 翻訳者 能仁 信亮 投稿日 2010年10月9日

セクション

設計/アーキテクチャ

トピック

Java One ,

Java ,

言語 ,

Concurrency ,

Architecture ,

パフォーマンス&スケーラビリティ ,

プログラミング

共有 |

原文(投稿日：2010/09/30)へのリンク

Brian Goetz氏とCliff Click氏は、先週行われたJavaOne conferenceにおいて、ハードウェアの観点から、並列処理の進化について講演を行った。氏らが最初に指摘したのは、最近までクロック数が指数関数的に伸びてきていたが、今後はそれほどの伸びは期待できないであろうといったことであった。ここ数年、CPU設計者はクロック数の増加や命令レベルの並列性(ILP)などのテクニックをつかって、シーケンシャルな処理のパフォーマンスを上げようとしてきたが、このアプローチには限界があった。CPUを進化させるために、設計者はスループットをあげるための並列化に注力するようになるだろう。

Brian氏はCISCとRISCシステムの時代および現在のマルチコアマシンの時代を含むCPUの歴史を概観した。Cliff氏は、データキャッシュのシステムパフォーマンスへの影響について論じた。氏が語ったところでは、一般的な原則として、開発者はコードではなく、データについて考えるべきだという。データの局所化は、パフォーマンスを求められるソフトウェアにとって、主要な設計時の関心事項となるべきである。また、共有を減らし、変更を減らすという原則も重要だ。キャッシュコネクションおよび同期が必要になるので、変更可能なデータを共有するのは望ましくない。

アプリケーションで並列化を実現するためのソリューションは次のようなものだ。

• スレッドプールとワークリスト: スレッドプールとワークキューを利用したアプローチは、それなりの規模のリクエストがくるデータベースやFile、Webサーバなどのサーバアプリケーションなどを含む、目の粗い並列処理には適したソリューションだ。この処理のライブラリサポートはJDK 5で追加されている。
• Fork/Join: Fork/Joinテクニックは、再帰的分解処理に利用される。この方式は軽量なCPU依存のメモリに収まる問題に向いている。しかし、I/O依存の処理には、あまり向いていない。Fork/joinフレームワークは、既にOpenJDKプロジェクトで利用可能であり、JDK 7リリースの一部となる予定だ。
• Map/Reduce: Map/Reduceアプローチはクラスタ内にデータ問い合わせを分散処理させるのに利用される。この方式はとても巨大な入力データセット(通常は分散して配置されている)を前提に設計されており、このフレームワークは分散、信頼性、スケジューリングなどの関心事項をこなす。Map/Reduceを使うためのHadoopのようなオープンソース実装が利用可能である。
• Actors: アクターモデルでは、状態は共有されず、すべての変更可能な状態はActorの中に限定される。Actorは、互いにメッセージを送信することで会話を行う。このモデルは、Erlang とScalaでうまく機能しており、Javaでもおそらくうまくいくであろう。しかし実装を行うには、さらなる訓練が必要となる。
• ソフトウェアトランザクショナルメモリ(STM): ソフトウェアトランザクショナルメモリ方式は、「並列処理のためのガベージコレクション」として語られてきた。この方式は、Clojure言語で機能している。なぜなら、Clojureはほとんど関数型言語であり、変更可能な状態を制限しているからだ。
• Graphics Processing Unit: Graphics Processing Unit(GPU)は、複数の単純なコアをもち、大量のデータに対して同じ処理を行うことに向いている。これらはCUDAやOpenCL、MicrosoftのDirectComputeなどのAPIで広くサポートされている。

講演者はプレゼンテーションを次のように締めくくった。「CPUは、覆いの下で成長してきて、パフォーマンスモデルは既に変化しており、新しいアプローチは、シンプルで多数のコアを持つ方式だ。」また、氏らはアプリケーション開発の初期フェーズから並列コンピューティングの必要性を考慮に入れるべきだと示唆した。