マルチコア CPU

November 08, 2004

マルチコア CPU

今後の CPU はこれまでのように単一コアの IPC やクロックを上昇させることで性能向上を目指すのではなく、マルチコア化によって性能向上を目指すようになる、という話。
かぴのすけが次のテーマだというので引用してみた。僕自身はマルチコアの流れは大歓迎で、どんどん分散化されていってしまいには環境に溶けこむくらいまでいって欲しい。靴にもマルチコア、T シャツにもマルチコアですよ。
マジメな話、ごく普通のクライアントアプリケーション達ももっとマルチコアの恩恵をあずかれると思う。Flash UI はたくさんの小さな MovieClip の集積だけど、あの MovieClip それぞれにリアル Thread 張りつかせて動作させたり。Web ブラウザでのブラウジング中だってページ中の画像や Movie 表示を Thread 化して複数のコアにレンダリングさせてみたり。もーぜんぶ Flash みたいな方法論で書くようにすれば、マルチコア化にしたがってじゃかじゃかパフォーマンスが上がる。アムダールの法則なんてどこふく風だよ。

SAK (Tue, 09 Nov 2004 12:56:01): アムダールの法則に呪いあれっ!!(逆ギレ)
かぴのすけ (Tue, 09 Nov 2004 22:37:30): > 靴にもマルチコア、T シャツにもマルチコア

キミのハートに○チコア！。とか。

プレスリーのアーキなんかはまさに「キャラごとにプロセッサコア」を狙ってるっぽい。個々のプロセッサコアはイベントを受け取ってそれに対するキャラのリアクションを計算するといった感じ。ゲームコンソールにはヒジョーに向いてるアーキテクチャーだ。

ＰＣなら例えばウインドーズの個々のＧＵＩ部品なんかはCOMのオブジェクトなんでこれらの単位で並列に動かせば良かろう。つーかもともとアウトプロセスなCOMはそんなアーキテクチャ。

ちなみにＩＥなんかの実行中情報取得、制御をしたければ GetActiveObject() を使えばよろしい。つーこと。
Digitune (Wed, 10 Nov 2004 08:57:18): 何で逆切れしとんじゃ＞SAK(笑
Digitune (Wed, 10 Nov 2004 09:01:11): プレスリーって何のことかと思ったぞ。エルヴィスか？
次世代 PS のことね。

ところでマルチコア対応ソフトを積極的に増やすためには、OS 側もそれに対応しなければならん。Thread 生成コストを極限まで減らして、全ループを thread で置き換えられるくらいにしよー。

ループのないプログラミング言語。ループしたかったらその数だけ thread 生成しろと。各 iteration に依存関係があるよーなコードを書く奴はヘボ。そういうループは全部展開しやがれ、ってんだ。

つーこと。
SAK (Wed, 10 Nov 2004 12:51:13): ムーアの法則よ、永遠なれ!!(無理)

さて、
>各 iteration に依存関係があるよーなコードを書く奴はヘボ。
今後、でじつね氏の書くループで、こ〜ゆ〜依存関係が出てくるたびに、
「ヘボ」と言ってあげやう。
Digitune (Wed, 10 Nov 2004 13:08:35): > ムーアの法則よ、永遠なれ!!(無理)

このブルートフォース信者がっ！！原子サイズの壁にとっととぶちあたりやがれ。

> 「ヘボ」と言ってあげやう。

俺がヘボなのは自明なのでモーマンタイ。
かぴのすけ (Thu, 11 Nov 2004 00:08:13): > エルヴィスか？

もちろんだ。もみあげ。

続きの記事によると PARROT はハード版トラメタみたいな感じで大して面白くもない感じ。イヒシオンの延長でコアを増やしまくってソフト対応した方がカッチョいいだろうよと。

今時分のマルチコアのトレンドはＣＰＵ内部で依存関係を見破ってマイクロオペレーションごとに並列化する方式らしい。スレッドによる並列化なんか効率悪すぎ。

ループをなくすつーと、まあ基本的には各処理をデータ中心のイベントドリブン型にすればいーのかなと。単純な処理なら一個のコアでループった方が速かろうと思うので適当なレベルで固まりを作る。データに対して処理がくっつくよーなイメージだからまさにＯＯなモデルが最適っぽい。

例えば配列に迷路を作る場合なら、

for(j = 0; j < m; j++){
for(i = 0; i < n ; i++){
makemaze(maze[i][j])
}
}

が

for(j = 0; j < m; j++){
for(i = 0; i < n ; i++){
maze[i][j].make();
}
}

となり、maze[][] ごとに非同期で動作する（要はスレッド作る）よーなフィーリング。コヒーレンシーとかは知らん。
Digitune (Thu, 11 Nov 2004 12:18:46): PARROT は名前の略語が強引過ぎで笑った。僕も Efficeon の方が好きだなぁ。

> スレッドによる並列化なんか効率悪すぎ。

ちゅーか、「スレッド」という言葉が悪いんだな。マイクロオペレーション毎に並列化するにせよもっと大きな単位で並列化するにせよ、各コアはそれぞれプログラムカウンタ (PC) を持って実行するパスというのがあるわけだ。じゃ、これからそういうのは「パス」と呼ぶことにしよう。

OO なモデルだと確かに同期問題とかも論理的には綺麗に見せられるね。異なるインスタンスをコールする時には常に新たな「パス」が生じる (非同期呼び出ししか出来ない OO 言語) とか、ちょっと面白いかも。まー普通なら選択可能にするだろーけどさ(笑。

どっちにせよ「パス」生成コストは極小化する必要があるね。少なくとも旧来のユーザランド・スレッドくらいにはなってほしいものだ。
ささだ (Sat, 13 Nov 2004 14:51:28): 従来のユーザスレッドライブラリでも、Intel のアーキテクチャを利用する場合、pthread の場合もろもろで数百命令ほど実行していたかと思います。数十命令ほどの命令列（パス？）では並列化してもペイしません。

・・・多分。
ささだ (Sat, 13 Nov 2004 14:52:21): あ、スレッドの生成が、です。処理系がすでにあるカーネルスレッドに対して処理を振るようなモデルだと、また違うかもしれません。
Digitune (Sun, 14 Nov 2004 19:05:36): うむむ。的確なツッコミありがとうございます＞ささださん。

http://pc.watch.impress.co.jp/docs/2004/1112/kaigai133.htm
↑Gelsingerさんも「アムダールの法則なんてなんぼのもんじゃ！」って言ってますね＜言ってない言ってない・笑。「これからのアーキテクチャ」を実現するには、きっと OS も大きく変わっていかないといけないのでしょうね。

http://pcweb.mycom.co.jp/articles/2004/11/11/hpc/
↑こちらでは「また、あらかじめ並列処理を前提にしたプログラム開発は人間には困難であり、これまで通り、人間には逐次処理のプログラム開発を行ってもらい、コンパイラの自動並列化技術でマルチプロセッサベースのコンピュータの性能向上を目指すという。」なんて書いてありますが、自動並列化技術の進展自体は歓迎すべきことながら、「あらかじめ並列処理を前提にしたプログラム開発は人間には困難」というのは言いすぎのような。

僕から見ると、現行のプログラミング言語は必要以上に逐次的に処理を記述することを強制されているように感じます。プログラムから「不必要な前提・後続関係」を自然と取り除けるような言語／環境があればいいのかもしれませんね (「並列化を意識する」のではなく逆に「依存性を意識する」ような環境。Flash なんかははからずもそういう環境になっているような＜ってまたそれか)。

ちなみにかぴのすけも気にしてるメモリ競合やらコヒーレンシーなどの問題は、そっちはそっちで独立して最適化して欲しい所存。そもそもキャッシュもソフトウェア的には透過的に扱えるのが売りの一つであるわけで (例えば PS2 にあるようなスクラッチパッドメモリはその逆の発想)、それをソフトウェアレイヤで意識するのは面倒だし、本末転倒な気がします。キャッシュ、ローカルメモリ、リモートメモリ、ストレージまでひっくるめて、可能なかぎり性能が良くなるよう最適に割り振るのはハードウェア＆OS の仕事だと思う。

Prev | Next

マルチコア CPU

マルチコア CPU

コメント