いまだに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]

y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> 新城＠筑波大学情報です。こんにちは。
>
> 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