いまだにIBMにあこがれるIntel
Shinji KONO
クアッドコアIA-64プロセッサ「Tukwila(タックウイラ)」
http://pc.watch.impress.co.jp/docs/2008/0208/kaigai418.htm
RISC vs CISC の論争は、命令デコードに多段パイプラインが導入
されて変換やらout of order とかが導入された時に無意味になっ
たと思う。PowerPCなんか泣いちゃうほど複雑だし。でも、VLIWは
だめなアイデアだってのが僕の持論。
32bit命令を三つたばねて128bit命令にしたのがIA-64のVery long
instruction set。こいつをコンパイラレベルでハードウェアに最
適に並べ換える。一種の水平マイクロなので、チップ内部で使う
なら良いんだけどさ。
もしIA-64がIBM 360みたいにマイクロコードレベルで互換性があ
って、あらゆる命令の実行クロックが将来に渡って同じだったら、
それでも良かったと思う。でも、現実には、どんどん異なるハー
ドウェアが出て来てしまう。実際、VLIWのバイナリ互換は制約で
しかない。その時その時のデバイス技術で、どういう命令(VLIWの
一部)が速く実行できるかなんて変わってしまう。マシンが変わる
たびにソースからコンパイルし直すの? JIT/Runtime compile っ
ていう手もあるけど、最適化にかけられる時間は限られてしまう。
命令レベルの並列性(ILP)に予測性があるってのも嘘だと思う。実
際にはキャッシュがあるわけだから、load/store のタイミングは
本質的に予測不可能。結局、20年前のデルコネアHEPみたいに、予
測不可能な遅延をスレッドレベルの並列性(TLP)で吸収する方が効
果がある。命令レベルの並列性は3-4程度なので、キャッシュとメ
インメモリのアクセス時間差を吸収できるほどではないってこと
でもある。
CPU同士が継るQuick Pathが結構たくさん用意されていて、キャッ
シュを介したコストの高いspin lockよりもハードウェア的、ソフ
トウェア的に軽くて高速なInter-thread 通信が可能になっている。
でも、それ自体、予測不可能な要素なので、VLIWと両立しない。
さらに、CPU同士が密に継って動くアプリケーションって極めて難
しい。不可能だとは思わないけど、プログラミングパラダイムか
ら変えてかないと書けないよ。それで動作クロックがあがるとい
うなら、まだ理解できるんだけど、実際には逆だし。
それでも、IntelがIA-64にしがみつくのは、やっぱりメインフレ
ームに対するあこがれがあるからなんだと思う。ハードウェアと
ソフトウェアの複雑さ、コンパイラ技術、バイナリ互換性、大規
模なチップ、大規模なサーバ。ハードウェア会社は、やっぱりメ
インフレームが一番儲かるからね。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
Yasushi Shinjo
In article <3993646...@leo.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 32bit命令を三つたばねて128bit命令にしたのがIA-64のVery long
> instruction set。こいつをコンパイラレベルでハードウェアに最
> 適に並べ換える。一種の水平マイクロなので、チップ内部で使う
> なら良いんだけどさ。
そうなんですか。32x3で96だけど。
> その時その時のデバイス技術で、どういう命令(VLIWの
> 一部)が速く実行できるかなんて変わってしまう。マシンが変わる
> たびにソースからコンパイルし直すの?
ソースからコンパイルする必要はないです。PowerPC -> Intel の
変換というのも、動いているし。
> RISC vs CISC の論争は、命令デコードに多段パイプラインが導入
> されて変換やらout of order とかが導入された時に無意味になっ
> たと思う。PowerPCなんか泣いちゃうほど複雑だし。でも、VLIWは
> だめなアイデアだってのが僕の持論。
命令はとりあえず fetch して詰めるという話なら、語長が長い方
が有利って単純な話はアリ？
> それでも、IntelがIA-64にしがみつくのは、やっぱりメインフレ
> ームに対するあこがれがあるからなんだと思う。ハードウェアと
> ソフトウェアの複雑さ、コンパイラ技術、バイナリ互換性、大規
> 模なチップ、大規模なサーバ。ハードウェア会社は、やっぱりメ
> インフレームが一番儲かるからね。
というよりは、単純な話、インテル自身、IA-32 を打ち止めにした
かったのに、今のところ失敗しているということなのでしょう。
AMDのせいで。10年後も IA-32 とか使っているのは、考えると暗く
なります。本当に、そろそろいい加減にして欲しい。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Shinji KONO
In article <YAS.08Fe...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> In article <3993646...@leo.ie.u-ryukyu.ac.jp>
> > 32bit命令を三つたばねて128bit命令にしたのがIA-64のVery long
> > instruction set。こいつをコンパイラレベルでハードウェアに最
> そうなんですか。32x3で96だけど。
残りはpredicationとかのフラグに使われているようですね。
> ソースからコンパイルする必要はないです。PowerPC -> Intel の
> 変換というのも、動いているし。
それは可能でしょうけど...
> 命令はとりあえず fetch して詰めるという話なら、語長が長い方
> が有利って単純な話はアリ？
スループット的には、むしろ圧縮したいかな。
> というよりは、単純な話、インテル自身、IA-32 を打ち止めにした
> かったのに、今のところ失敗しているということなのでしょう。
> AMDのせいで。10年後も IA-32 とか使っているのは、考えると暗く
> なります。本当に、そろそろいい加減にして欲しい。
でも、PowerPCも結構悪夢ではあるんだけど。Cacheのprefetchとか...
AMDの64bitは割とバランス良いと思うんだけど、そうでもないですか?
Yasushi Shinjo
In article <3993668...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> AMDの64bitは割とバランス良いと思うんだけど、そうでもないですか?
x86-64 でしたっけ。まあ、「バランスがいい」と言えば、そうな
んだけれども、今一つ夢がないとというか。
x86-64 は、AMD の後追いで、Intel も出したという所まではなん
となく記憶があるのですが、その後、どうなったんでしたっけ？
Intel Core は、その系列？
そういえば、Linux 2.6.24 で、arch/i386 が無くなって、
arch/x86 というのができてました。x86-64 は、arch/x86 の方み
たい。
Yoshitaka Ikeda
> 新城＠筑波大学情報です。こんにちは。
>
> In article <3993668...@rananim.ie.u-ryukyu.ac.jp>
> ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
>> AMDの64bitは割とバランス良いと思うんだけど、そうでもないですか?
>
> x86-64 でしたっけ。まあ、「バランスがいい」と言えば、そうな
> んだけれども、今一つ夢がないとというか。
最近は、x64なんて呼ばれ方もします。LinuxとかPC-UNIXの一部では
amd64とも。
> x86-64 は、AMD の後追いで、Intel も出したという所まではなん
> となく記憶があるのですが、その後、どうなったんでしたっけ？
> Intel Core は、その系列？
Core2や今のXeonはその系列ですね。
Intel Macも今売ってるのはx86-64ばっかりですな。
> そういえば、Linux 2.6.24 で、arch/i386 が無くなって、
> arch/x86 というのができてました。x86-64 は、arch/x86 の方み
> たい。
FreeBSDだとamd64って名前になってますな。
Windowsだとx64と書いてあるなぁ．
--
I LOVE SNOOPY! でつ
Yoshitaka Ikeda mailto:ik...@4bn.ne.jp
My Honeypot: ho...@4bn.ne.jp <-don't send this address