InfoQ

News

マルチコアプロセッサ時代のソフトウェアアーキテクチャインパクト

作者 Mark Figley, 翻訳者 編集部 投稿日 2007年9月28日 午前12時3分

コミュニティ
Java,
Architecture
トピック
パフォーマンス&スケーラビリティ
タグ
Threading,
Parallel Programming
The Java Developer's Jounal誌にソフトウェア開発者たちがマルチコアとパラレルプロセッサの時代によってどのような影響を受けるかという素晴らしい記事(source)が掲載された。記事の内容は以下のとおりである。

ソフトウェア開発者として、私たちはプロセッサ技術によって継続的に向上されてきたパフォーマンストレンドを楽しんできた。実のところ過去20年間プロセッサのパフォーマンス性は一貫して2年ごとに倍増してきたのだ。もしもこの向上ペースが遅くなったり、あるいはそれ自体止まってしまったりしたらどんな事態に なるだろうか。私たちはより大きく重い、優良なソフトウェアを作ることができるだろうか?実際のところシングルスレッドのパフォーマンス向上は、来る1年から3年の間で非常に緩くなるように思える。もしかしたらシングルスレッドパフォーマンス自体が無くなってしまう場合もあるかもしれない。今まで長い間維持 されてきた上昇率は劇的に弱まることだろう。

そのソースとなった雑誌の名前にも関わらず、その記事はもしあなたがJava派でなくても読む価値のある面白いものとなっている。想像できると思うがこの記事を読むと少し希望が持てる。また、その記事は今後の更なるソフトウェアの成長を見据えて、私たちがどのようにアーキテクチャを調節していく必要があるのかということに関して解説している。

パフォーマンスの向上継続を目指して、業界はマルチコアとマルチスレッドプロセッサに注目している。これらのデザインはシングルスレッドのパフォーマンスを向上させるとは思えないが、たくさんのもしくは膨大な数のスレッドを並列で処理させるように思える。開発者としてこのように増加するパラレルプロセッサ上での高パフォーマンス性と、並列処理できるアプリケーションを開発するためのスキルを学ぶのは欠かせないことである。シングルスレッドパフォーマンスは歴史的な上昇率の改善には貢献しないが、開発者達は与えられたタスクのパフォーマンスを向上させるのにはJavaの一致性に目を向ける必要があるのだ。

またその記事にはAmdahlの法則と共にパラレルプログラミングストラテジーへの入門知識に関しても掲載されている。

並列プログラミングを始めるとき、一番初めにしないといけないのはAmdalsの法則に親しくなることである。Amdahlの法則はプログラムの加速は並列に処理していない部分によって制限されていると述べている。例えばもしプロファイルで一つのプロセッサの時間の20%を連続的に占めるコードが使用されていると表した場合、プロセッサを何個そこに投与しようが、その処理性能の上昇率は1/(1-0.2)=1.25倍にしかならないのである。ダウンロードのアンバランス性はこの問題に似ている。もしあなたがコードをNサブタスクに分離させたらそれを実行する時間は1/Nではないのだ。むしろそれにかかる時間はサブタスクの実行時間の最大限のものであるのだ。

そして話題は並列プログラミング用のJava言語構築に焦点を当てながら一致性の問題とスレッドプログラミングへと移行する。そしてその記事は並列アプリケーションに特化したJava言語に高レベル構築を付け加える、IBMのX10(サイト・英語)という新たな言語に関して言及することによって幕を閉じている。それは並列処理とそれらの処理に関連しているデータの分配両方を管理するための簡易化された意味論を提供することによって並列プログラミングを簡易化することを目的としている。

X10はシンタックスが有効なJavaシンタックスではないので内部DSLとしてはみなされない。どちらかといえばそれは基礎としてJava言語を使用し、異なる新たな言語を構築するという点においてAspect Jに近いものと言えるだろう。

原文はこちらです:http://www.infoq.com/news/2007/09/multicore-processor-trend-impact
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。