アカウント名:
パスワード:
A64FXの話で「ISAの切り替えはあっさりだった」との話があったけど、Intelが普通に苦労してそうなのは何だろうな。なんならマイクロコードでファームウェアだけでまるっとスイッチできそうなイメージだけども。浮動小数点演算あたりが支配的なスパコンと、雑多なコードが走るオープン系、それも出荷数考えればパフォーマンスのチューニングが色々違うのかな？多少遅くて電力効率が悪くても仮想マシンのノリで実行中に命令セットを変更できたら便利なのにな。
富岳の話で行けば・実行する人はソースを持っている人なので、ターゲットに合わせてコンパイルし直せる・x86向けコードをJITで動かすスタックを開発 [opensource.srad.jp] ・A64FXに導入したSVEは元々「京」で使っていた技術の後継なので、元々の利用者は使い方がわかっているし速度も出やすいなどの理由があるので切り替えに成功したのだと思います。
Intelが苦労しているのは、・x86/x64の高速化機構（命令デコーダ、分岐予測）が非常に複雑で、他のISAでは使えない・他のISAを使う
インテルが苦労してるのはとどのつまりAMD64向けソフトウェア資産が最大の強みで足枷ってとこだろう。新命令セットへ移行したい気持ちはあるが客がついてこない新規顧客を獲得するのが面倒と。既存別命令セットの場合市場が小さいからとか特許料とかAMD64と違って諸々の参入障壁が少なく敵が多いとか。高速化テクニックは内部命令に変換後の話なんで正直命令セットはあまり関係ないと思う。むしろRISCにすればCISCゆえの無駄な処理がなくなりより高速化できる確率が高い。大体京から富嶽は基本的には人気命令セットから人気命令セットへの移行なんでそりゃすんなり行くだろうと。
IntelがARM、RISC-Vにしたとして、余計な機構を省ける分高速化あるいは省電力化できると思いますが、それはIntelの強みにならないです。別に他の安いファウンドリにお願いしても同じ、となればIntelがこの領域で勝つのは難しい。なのでARM、RISC-Vに対しIntelのカスタムで高速化できれば強みになると思うのですが、x86/x64で培ってきたノウハウをそのままは使えないという点で苦労と表現しました。
あと、京のCPU命令セットはSPARCなんですけど、これを人気命令セットなんて言う人初めて見ました。死にかけのアーキテクチャという認識なんですが……
x86/x64で培ってきたノウハウはぶっちゃけMicroOpの方にあるので命令セットが変わっても割とそのまんま流用できるという想定です。内部命令が他と異なる外向けの命令セットだけ同じプロセッサのハード、IPが売れるかどうかは知らん。コンパイラが吐き出す機械語なんてどうせプロセッサがデコードついでに再コンパイルするからどうでもいい。
PentiumProの頃のuopはRISCっぽい感じだったが、今はx86の命令をなるべくそのまま扱うようになっている。インテルが詳細を語らなくなったのでわからないが、op reg, memなら1uopじゃないかな。op mem, regは2uopにする。ATOMはそう。Centaurのもそう。まあ最後にはロードと演算は実行ユニットが違うから分解するわけだが、ロード→演算という明白で直接的な依存関係があるので、一般的なデータの待ち合わせユニットからオフロードすることができる。RISCにはこれがない。
> ロード→演算という明白で直接的な依存関係があるので、一般的なデータの待ち合わせユニットからオフロードすることができる。
いいえ、Alder lakeのPコアのGolden Coveのブロックダイアグラムはそんな構造にはなっていません。Apple A15やCortex-X2と同様にGolden Coveの演算パイプラインとロードストアパイプラインは完全に独立しています。
Alder lakeのEコアのAtom由来のGracemontも同様で、そもそもA15やCortex-X2に極めて類似したバックエンド構造になっています。ZenやZen2も同様です。
Zen3はALUのパイプラインとAGUのパイプライン2本をひとまとめにしてスケジューリングしている点が異なりますが演算パイプラインとロードストアパイプラインが独立していることに変わりはありません。
現行のIntel CPUもAMD CPUも内部構造は今もロードストアアーキテクチャのまま何も変わっていません。それに、x86_64の規定するmemory ordering(バイトオーダーのことではない)は制限の強いTotal StoreOrderingで、Weak OrderingのARMやRISC-Vの方がよりメモリアクセスの最適化が可能となっており、むしろメモリ周りはARMやRISC-Vの方が優位です。
うむ。
低並列度で高性能向けだとデコーダやOoOの複雑さをトランジスタ数で殴って直接解決できるようになったCISCが断然有利。まあ限度はあるけど。作れるトランジスタ数が絶対的に足りない今世紀初頭くらいまではRISCの出る幕もあったけど、今となってはねぇ。
逆に並列数で性能稼ぐ方面はどうしても省電力のニーズが出てくるのでスーパーコンピュータだとRISCが強い。コンシューマ向けみたいなソフトウェア資産の問題も少ないし。
スーパーコンピュータの事情とPCの事情は全く異なるので同列に議論するのは無理だね。
俺> まあ最後にはロードと演算は実行ユニットが違うから分解するわけだが
> 演算パイプラインとロードストアパイプライン
こう書いたが、君の言っているのはこのことだろう。
俺が書いたのはスケジューリングの話で、CISC命令を分解するのをなるべく遅らせる、ロードしてすぐ使いそれ以外では二度と使われない短命なデータ(バイパスで渡せばいいからレジスタエントリを確保する必要がない)における最適化がx86では可能で、RISCの半分の16本のレジスタしかないという弱点をある程度補える。昔みたいにop reg,memをさっさと分解してしまうとuopが増えるし短命性の情報も失われ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
ISAの切り替え (スコア:0)
A64FXの話で「ISAの切り替えはあっさりだった」との話があったけど、Intelが普通に苦労してそうなのは何だろうな。
なんならマイクロコードでファームウェアだけでまるっとスイッチできそうなイメージだけども。
浮動小数点演算あたりが支配的なスパコンと、雑多なコードが走るオープン系、それも出荷数考えればパフォーマンスのチューニングが色々違うのかな？
多少遅くて電力効率が悪くても仮想マシンのノリで実行中に命令セットを変更できたら便利なのにな。
Re: (スコア:2, 興味深い)
富岳の話で行けば
・実行する人はソースを持っている人なので、ターゲットに合わせてコンパイルし直せる
・x86向けコードをJITで動かすスタックを開発 [opensource.srad.jp]
・A64FXに導入したSVEは元々「京」で使っていた技術の後継なので、元々の利用者は使い方がわかっているし速度も出やすい
などの理由があるので切り替えに成功したのだと思います。
Intelが苦労しているのは、
・x86/x64の高速化機構（命令デコーダ、分岐予測）が非常に複雑で、他のISAでは使えない
・他のISAを使う
Re: (スコア:0)
インテルが苦労してるのはとどのつまりAMD64向けソフトウェア資産が最大の強みで足枷ってとこだろう。新命令セットへ移行したい気持ちはあるが客がついてこない新規顧客を獲得するのが面倒と。既存別命令セットの場合市場が小さいからとか特許料とかAMD64と違って諸々の参入障壁が少なく敵が多いとか。
高速化テクニックは内部命令に変換後の話なんで正直命令セットはあまり関係ないと思う。むしろRISCにすればCISCゆえの無駄な処理がなくなりより高速化できる確率が高い。
大体京から富嶽は基本的には人気命令セットから人気命令セットへの移行なんでそりゃすんなり行くだろうと。
Re: (スコア:0)
IntelがARM、RISC-Vにしたとして、余計な機構を省ける分高速化あるいは省電力化できると思いますが、それはIntelの強みにならないです。
別に他の安いファウンドリにお願いしても同じ、となればIntelがこの領域で勝つのは難しい。
なのでARM、RISC-Vに対しIntelのカスタムで高速化できれば強みになると思うのですが、x86/x64で培ってきたノウハウをそのままは使えないという点で苦労と表現しました。
あと、京のCPU命令セットはSPARCなんですけど、これを人気命令セットなんて言う人初めて見ました。
死にかけのアーキテクチャという認識なんですが……
Re: (スコア:0)
x86/x64で培ってきたノウハウはぶっちゃけMicroOpの方にあるので命令セットが変わっても割とそのまんま流用できるという想定です。内部命令が他と異なる外向けの命令セットだけ同じプロセッサのハード、IPが売れるかどうかは知らん。
コンパイラが吐き出す機械語なんてどうせプロセッサがデコードついでに再コンパイルするからどうでもいい。
Re:ISAの切り替え (スコア:0)
PentiumProの頃のuopはRISCっぽい感じだったが、今はx86の命令をなるべくそのまま扱うようになっている。インテルが詳細を語らなくなったのでわからないが、op reg, memなら1uopじゃないかな。op mem, regは2uopにする。ATOMはそう。Centaurのもそう。
まあ最後にはロードと演算は実行ユニットが違うから分解するわけだが、ロード→演算という明白で直接的な依存関係があるので、一般的なデータの待ち合わせユニットからオフロードすることができる。RISCにはこれがない。
Re:ISAの切り替え (スコア:1)
> ロード→演算という明白で直接的な依存関係があるので、一般的なデータの待ち合わせユニットからオフロードすることができる。
いいえ、Alder lakeのPコアのGolden Coveのブロックダイアグラムはそんな構造にはなっていません。
Apple A15やCortex-X2と同様にGolden Coveの演算パイプラインとロードストアパイプラインは
完全に独立しています。
Alder lakeのEコアのAtom由来のGracemontも同様で、そもそもA15やCortex-X2に極めて類似した
バックエンド構造になっています。ZenやZen2も同様です。
Zen3はALUのパイプラインとAGUのパイプライン2本をひとまとめにしてスケジューリングしている点が
異なりますが演算パイプラインとロードストアパイプラインが独立していることに変わりはありません。
現行のIntel CPUもAMD CPUも内部構造は今もロードストアアーキテクチャのまま何も変わっていません。
それに、x86_64の規定するmemory ordering(バイトオーダーのことではない)は制限の強いTotal Store
Orderingで、Weak OrderingのARMやRISC-Vの方がよりメモリアクセスの最適化が可能となっており、
むしろメモリ周りはARMやRISC-Vの方が優位です。
Re: (スコア:0)
うむ。
低並列度で高性能向けだとデコーダやOoOの複雑さをトランジスタ数で殴って直接解決できるようになったCISCが断然有利。まあ限度はあるけど。作れるトランジスタ数が絶対的に足りない今世紀初頭くらいまではRISCの出る幕もあったけど、今となってはねぇ。
逆に並列数で性能稼ぐ方面はどうしても省電力のニーズが出てくるのでスーパーコンピュータだとRISCが強い。コンシューマ向けみたいなソフトウェア資産の問題も少ないし。
スーパーコンピュータの事情とPCの事情は全く異なるので同列に議論するのは無理だね。
Re: (スコア:0)
俺> まあ最後にはロードと演算は実行ユニットが違うから分解するわけだが
> 演算パイプラインとロードストアパイプライン
こう書いたが、君の言っているのはこのことだろう。
俺が書いたのはスケジューリングの話で、CISC命令を分解するのをなるべく遅らせる、ロードしてすぐ使いそれ以外では二度と使われない短命なデータ(バイパスで渡せばいいからレジスタエントリを確保する必要がない)における最適化がx86では可能で、RISCの半分の16本のレジスタしかないという弱点をある程度補える。昔みたいにop reg,memをさっさと分解してしまうとuopが増えるし短命性の情報も失われ