アカウント名:
パスワード:
これなぁ・・・「Itaniumとは一体なんだったのか」
記事本文からリンクされているASCII.jpの記事には「当時のインテルの考えは、x86は命令体系が複雑であり、将来性能を引き上げる際にはこの命令体系の複雑さがボトルネックになると考えていた」とあるが、なのでItaniumは32bitのx86と互換性がない設計になった、ということのようだが、それならどうして性能がポンコツだったのか・・・実際のところ、Itaniumの発売から20年近く経ち、現れたApple M1なんかは、x86より高効率と喧伝されているわけだが、当初の目論見では、Itaniumも、簡潔な命令セットで高効率で低消費電力で高性能、を目指していたのだろうか？どうしてそうなれなかったのか・・・。
> 当初の目論見では、Itaniumも、簡潔な命令セットで高効率で低消費電力で高性能、> を目指していたのだろうか？
Itanium の命令セットは簡潔とはとうてい言い難いですね。高速化を助けるためのありとあらゆるアイディアを詰め込んだ命令セットで、相当に複雑です。登場当時に既に嫌われていたレジスタウィンドウもどきもあります。もちろん年月を経てぐちゃぐちゃになっているx86に比べればそれでもシンプルですが。(x86はアセンブリ言語の命令ニーモニックで1000近く、機械語のオペコードを詳細に分類すると6000種類越えと数えることも可能)
VLIWもすでに嫌われていたと思うが。Itanium開発開始はいつだったんだろう。
Wikipedia情報だと1994年か。1994年にレジスタウィンドウやVLIWを採用する状況だったっけ?リリースが2001年ってそんな遅かったんだ。出る前に死んでたな。そういえば。
X86からの移行なんだからX86より簡素ならとりあえず命令の簡素化は合格だろう。あとはコンパイル時に最適化できるようにするって目標もあったようなので。それが逆にプロセッサの世代ごとにコンパイルが必要という結果を招いたようでもあるが。結局RISCライクな命令セットにしつつスケジューラを強化するのが正解かも。
そもそもダイサイズが300mm2と当時としては巨大だったのがMerced開発難航の理由だからな。どこが簡潔やねん
命令セットの簡潔さと回路の簡潔さは独立では？
デコーダとかが命令数や命令の複雑さに引きずられて大きくなるので完全に連動はしないが独立というほどでもない。
VLIWにしたのが失敗だったんだろうな。特許で囲うとか、互換性がないならRISCよりよいものを、とか、HPをファーストカスタマーにするとか、色々あったんだろうが。
Itanium は VLIW だったので、簡潔な命令セットとは対極な面倒な命令セットですねコンパイラが頑張ることで効率的な実行を目指していましたが、VLIW だといくつもの処理をまとめて 1 命令とかにしないと速度がでないので、頑張りきれなかったのかとあと Itanium2 では x86 を実行できたみたいですが、こっちの速度も出なかったようです
なお x86 自体は命令を後付けしている関係で複雑でデコーダの負荷とボトルネック具合が酷く、性能が上げられなかったのは事実です命令セットを一新しても互換性をエミュレータやトランスレータで対応できる M1 が x86 より高効率なのは確かですね
別にVLIWだから命令セットが複雑ってことはないんじゃないだろうか。
そうは言っても今メジャーなCPUアーキテクチャってx86(-64)とarmに集約されちゃって、乱立してたarm以外のRISC系アーキもニッチで生き残ってるくらいだしなぁ。
結局生き残ったのはローエンドから始まって徐々にハイエンドもカバーしていったx86とarmだってのは偶然なのか必然なのか。
ダウンサイジングを続けているうちに一番小型のものだけが残った印象
Itanium開発の話が出てきて、サーバーメーカーがItaniumへのくら替えを決め、作っても売れる見込みの無くなった他アーキテクチャが撤退しただけと認識している。2000年ころの話。
まだ影も形もないものを期待して他の選択肢を切り捨ててしまうなんて無茶なことをやるなと思ったもんだ。
> まだ影も形もないものを期待して他の選択肢を切り捨ててしまうなんて無茶なことをやるなと思ったもんだ。
Itaniumを開発中だったHPが、Alphaサーバー出してたDECを買収して Alphaを切り捨てたんですが、HP-UX / Itanium じゃなくて Tru64 / Alpha の方を残してれば、もう少し延命してた可能性もあるんじゃないかって気はしますね。OSもCPUも、DECの方が優秀だったような…まあ延命できてたとしても最終的な結果は同じだろうと言われるとその通りなんですが。
コンパイラに頑張らせればブランチ予測とかを減らせるから速くなるよ！→特定用途を除くと、コンパイラがいくら頑張ってもランタイム中のブランチ予測には勝てませんでした。こういうことかと。Apple M1が意外と速い理由の一つも、デコーダーが8命令分と異様に広く、ブランチ先読みに長けているからだと言われてますね。
IA-32のデコードの難しさとそれに伴う並列実行の困難さ（依存関係の解決が必要なため）から、IA-64はデコードを簡単にし、高度な並列実行を命令のフォーマットレベルで可能にしたものだと当時読んだ記憶があります。並列実行の計画はコンパイル時に行い、実行時にはそれをどんどん実行していけば性能がでるだろうという想定に基づいていたものの、実際にはコンパイル時に行った静的な並列化よりも実行時に並列化を動的に行うIA-32の方が性能が出るという事態になり、クロックあたりの性能が伸びずにとん挫したわけです。
当初のIA-64はIA-32のコードも実行でき
マイクロアーキを共有しつつデコーダ経由のIA32/x64とダイレクトに演算ユニットを指定するIA64、とか出来なかったのかね。そう簡単じゃないか。
命令セットの話ならM1がというよりARMv8がうまいことやったってだけじゃないのかとどうにももにゃる
> VLIWであることには大してメリットも害もないでしょう。
その上に君が上げた欠点は、全てVLIWであることに起因するものじゃないかｗ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
一体なんだったのか (スコア:0)
これなぁ・・・「Itaniumとは一体なんだったのか」
記事本文からリンクされているASCII.jpの記事には
「当時のインテルの考えは、x86は命令体系が複雑であり、将来性能を引き上げる際にはこの命令体系の複雑さがボトルネックになると考えていた」とあるが、なのでItaniumは32bitのx86と互換性がない設計になった、ということのようだが、
それならどうして性能がポンコツだったのか・・・
実際のところ、Itaniumの発売から20年近く経ち、現れたApple M1なんかは、x86より高効率と喧伝されているわけだが、
当初の目論見では、Itaniumも、簡潔な命令セットで高効率で低消費電力で高性能、
を目指していたのだろうか？どうしてそうなれなかったのか・・・。
Re:一体なんだったのか (スコア:1)
> 当初の目論見では、Itaniumも、簡潔な命令セットで高効率で低消費電力で高性能、
> を目指していたのだろうか？
Itanium の命令セットは簡潔とはとうてい言い難いですね。
高速化を助けるためのありとあらゆるアイディアを詰め込んだ命令セットで、相当に複雑です。
登場当時に既に嫌われていたレジスタウィンドウもどきもあります。
もちろん年月を経てぐちゃぐちゃになっているx86に比べればそれでもシンプルですが。
(x86はアセンブリ言語の命令ニーモニックで1000近く、機械語のオペコードを詳細に分類すると6000種類越えと数えることも可能)
Re: (スコア:0)
VLIWもすでに嫌われていたと思うが。
Itanium開発開始はいつだったんだろう。
Wikipedia情報だと1994年か。
1994年にレジスタウィンドウやVLIWを採用する状況だったっけ?
リリースが2001年ってそんな遅かったんだ。出る前に死んでたな。そういえば。
Re: (スコア:0)
X86からの移行なんだからX86より簡素ならとりあえず命令の簡素化は合格だろう。
あとはコンパイル時に最適化できるようにするって目標もあったようなので。それが逆にプロセッサの世代ごとにコンパイルが必要という結果を招いたようでもあるが。
結局RISCライクな命令セットにしつつスケジューラを強化するのが正解かも。
Re: (スコア:0)
そもそもダイサイズが300mm2と当時としては巨大だったのがMerced開発難航の理由だからな。どこが簡潔やねん
Re: (スコア:0)
命令セットの簡潔さと回路の簡潔さは独立では？
Re: (スコア:0)
デコーダとかが命令数や命令の複雑さに引きずられて大きくなるので完全に連動はしないが独立というほどでもない。
Re: (スコア:0)
VLIWにしたのが失敗だったんだろうな。
特許で囲うとか、互換性がないならRISCよりよいものを、とか、HPをファーストカスタマーにするとか、色々あったんだろうが。
Re: (スコア:0)
Itanium は VLIW だったので、簡潔な命令セットとは対極な面倒な命令セットですね
コンパイラが頑張ることで効率的な実行を目指していましたが、VLIW だといくつもの処理をまとめて 1 命令とかにしないと速度がでないので、頑張りきれなかったのかと
あと Itanium2 では x86 を実行できたみたいですが、こっちの速度も出なかったようです
なお x86 自体は命令を後付けしている関係で複雑でデコーダの負荷とボトルネック具合が酷く、性能が上げられなかったのは事実です
命令セットを一新しても互換性をエミュレータやトランスレータで対応できる M1 が x86 より高効率なのは確かですね
Re: (スコア:0)
別にVLIWだから命令セットが複雑ってことはないんじゃないだろうか。
Re: (スコア:0)
そうは言っても今メジャーなCPUアーキテクチャってx86(-64)とarmに集約されちゃって、乱立してたarm以外のRISC系アーキもニッチで生き残ってるくらいだしなぁ。
結局生き残ったのはローエンドから始まって徐々にハイエンドもカバーしていったx86とarmだってのは偶然なのか必然なのか。
Re: (スコア:0)
ダウンサイジングを続けているうちに一番小型のものだけが残った印象
Re: (スコア:0)
Itanium開発の話が出てきて、サーバーメーカーがItaniumへのくら替えを決め、作っても売れる見込みの無くなった他アーキテクチャが撤退しただけと認識している。
2000年ころの話。
まだ影も形もないものを期待して他の選択肢を切り捨ててしまうなんて無茶なことをやるなと思ったもんだ。
Re: (スコア:0)
> まだ影も形もないものを期待して他の選択肢を切り捨ててしまうなんて無茶なことをやるなと思ったもんだ。
Itaniumを開発中だったHPが、Alphaサーバー出してたDECを買収して Alphaを切り捨てたんですが、
HP-UX / Itanium じゃなくて Tru64 / Alpha の方を残してれば、もう少し延命してた可能性もあるんじゃないかって気はしますね。
OSもCPUも、DECの方が優秀だったような…
まあ延命できてたとしても最終的な結果は同じだろうと言われるとその通りなんですが。
Re: (スコア:0)
コンパイラに頑張らせればブランチ予測とかを減らせるから速くなるよ！→特定用途を除くと、コンパイラがいくら頑張ってもランタイム中のブランチ予測には勝てませんでした。
こういうことかと。
Apple M1が意外と速い理由の一つも、デコーダーが8命令分と異様に広く、ブランチ先読みに長けているからだと言われてますね。
Re: (スコア:0)
IA-32のデコードの難しさとそれに伴う並列実行の困難さ（依存関係の解決が必要なため）から、IA-64はデコードを簡単にし、高度な並列実行を命令のフォーマットレベルで可能にしたものだと当時読んだ記憶があります。
並列実行の計画はコンパイル時に行い、実行時にはそれをどんどん実行していけば性能がでるだろうという想定に基づいていたものの、実際にはコンパイル時に行った静的な並列化よりも実行時に並列化を動的に行うIA-32の方が性能が出るという事態になり、クロックあたりの性能が伸びずにとん挫したわけです。
当初のIA-64はIA-32のコードも実行でき
Re: (スコア:0)
マイクロアーキを共有しつつデコーダ経由のIA32/x64とダイレクトに演算ユニットを指定するIA64、とか出来なかったのかね。
そう簡単じゃないか。
Re: (スコア:0)
命令セットの話ならM1がというよりARMv8がうまいことやったってだけじゃないのかとどうにももにゃる
Re: (スコア:0)
> VLIWであることには大してメリットも害もないでしょう。
その上に君が上げた欠点は、全てVLIWであることに起因するものじゃないかｗ