日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

未来 >>

パイプライン処理の世界

研究希望調書書くためにいろいろネタを集めているが、なかなか難しい。

この志願しようとしている研究室がコンピュータのハードウェアを扱っているのだが、

コンピュータのハードウェアのことを調べると、専用の信号処理用のハードウェアとは違う点が多い。

それを踏まえてテーマも決めないとつらいなぁって。


なにが違うかというと、コンピュータのCPUは命令を与えてそれに応じて動かすことか。

命令をフェッチして、デコードして、実行して、メモリアクセスして、ライトバックする、という流れで動いている。

なので1つ命令を動かすのもけっこうめんどくさい。

そこでパイプライン処理といって、各演算ユニットを独立に動かすことで高速化を図っている。

命令1を実行してるとき、次の命令2をデコードして、次の命令3をフェッチしてるとかそういうの。


とはいうものの、そううまくいく話でもない。

命令間にデータの依存関係があったりすると思うように行かない。

そこで依存性がないかチェックしながら読み込んでいく必要がある。

命令の順序を入れ替えることで依存性を減らしパイプライン処理の実効性を上げることも行われる。アウトオブオーダー実行っていうんだが。

データの依存はまだましだが、問題は分岐があるときで、分岐先がわからないと思うようにはいかない。

そこで分岐予測をしたりとか複雑なことをしてるようで。


なんでこんな話をしたのかというと、自分の思いついたアイデアが志望している研究室ですでに取り組まれていて、

そこでVLIWを使う話が出ていて、上手いやり方だなぁと思って見てたんだわ。

VLIWというのはVery Long Instruction Wordの略で、長い命令って意味か。

これもパイプライン処理と関係があって、さっき挙げた、命令フェッチからライトバックまでの演算ユニットそれぞれに対して並列に命令を与えるから長くなると。

コンパイラで依存関係とかチェックして、命令を生成すると。そういう考えですね。

動かさないユニットにはNOP命令を与えて休ませる。そんなんだから命令サイズが大きくなるが、そのへんは圧縮する技術もあるよう。

ただ、いまいち流行らなかったようで。というのも、CPUが変わるごとにコンパイルし直さないといけないから。

組み込み用途で考えればその程度大したことないやん、と思うところだが、汎用のコンピュータでこれは相当不便なことらしい。

そこで、汎用のCPUではスーパースカラーというCPU上でパイプライン処理のためのスケジューリングをする方法が主流となって、

GPUとかではVLIWも使われてたけど、これも最近は流行らなくなってきたんだとか。


この辺の話を調べてて思ったのは、CPUで高速化しにくい最たるものは分岐らしいということですね。

データの依存性はアウトオブオーダー実行とか、工夫のしようはあるが、分岐は本質的にどうしょうもない。

確かに、自分の作った回路を振り返ってみても、分岐する場合は、分岐先の計算を2つともしてそのどちらかを選択するようなことが多い。

しかし、これは計算した一方は無駄になると言うことで効率が悪い。速度重視の力業といったところか。

現実には一方にアテをつけておいて、当たったらしめしめ、外れたらこれを捨てて、新しく計算するということをしている。

この辺がバランスがいいというのが現実なんだろう。


パイプライン処理界隈の事情はこんな感じらしい。

しかし、コンピュータのハードウェアというのはプログラムを動かすのが前提だから、

やはり専用のハードウェアとはいろいろ事情が違って難しいね。

高速にデータ処理するならこういうハードウェアがいいけど、プログラムから扱えるかというとそう簡単ではないと。

さて、どういうネタに落とし込むか。難しいが、さっさと落としどころを見いだしたいところ。


Author : Hidemaro
Date : 2012/05/28(Mon) 23:56
コンピュータ・インターネット | Comment | trackback (0)
blog comments powered by Disqus

トラックバック

トラックバックURL取得

Tools