アカウント名:
パスワード:
昔は貧弱なリソースのせいで、命令セットによる性能差は確かに存在してました。ただ、今日では命令セットによる差なんて微々たるもので、ARMじゃないと性能でないなんてことはありません。Intel自身にしたって、小面積低消費電力のAtom系とPC向けのCore系で命令セットにはほとんど差がありません。外から見える命令セットではなく、より下位のマイクロアーキテクチャによっていくらでも作り変えられるので、x86から離れる必要は全くないでしょう。
それより、Intelのプロセス技術とか回路技術がすごすぎて、アーキテクチャなんて関係なくIntelの覇権が続くんじゃないかと予想しています。
以前は重荷になっていたx86の命令デコーダーも今やダイに占める割合は数%まで下がってますからね今でもボトルネックの一つではあるのですが、相対的に影響度は下がってますIntelもわかっていて、デコーダーがなるだけ働かなくても良いようにいろいろ工夫してますし(sandy bridge以降のuop cache)
>Intelのプロセス技術とか回路技術がすごすぎて全く同感です。そろそろIntel以外の全メーカーを周回遅れにしそうな勢いだもんなぁ
以前は重荷になっていたx86の命令デコーダーも今やダイに占める割合は数%まで下がってますからね
いまどきのプロセッサはキャッシュがでかいから命令デコード部分が全体の割合として小さくなってるというだけで、複雑なことに変わりはないんじゃないの。
x86は命令が可変長で、命令の区切りは先頭からデコードしてみないとわからないという特徴があります複数命令同時デコードというのはつまるところ総当たりでデコードしてみて正しい結果だけ利用するということになります(実際はデコードに複数サイクルかけたり、並列にデコードできる組み合わせを制限したりしていますが)
命令デコーダーは非常にビジーなユニットで、かつ結果をほとんど捨ててしまうので、電力的に大きな損失になりますまた、同時デコード数を増やすと回路規模は組み合わせ論的に増えていきます
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
x86アーキテクチャから離れる必要がないから (スコア:3)
昔は貧弱なリソースのせいで、命令セットによる性能差は確かに存在してました。
ただ、今日では命令セットによる差なんて微々たるもので、ARMじゃないと性能でないなんてことはありません。
Intel自身にしたって、小面積低消費電力のAtom系とPC向けのCore系で命令セットにはほとんど差がありません。
外から見える命令セットではなく、より下位のマイクロアーキテクチャによっていくらでも作り変えられるので、
x86から離れる必要は全くないでしょう。
それより、Intelのプロセス技術とか回路技術がすごすぎて、アーキテクチャなんて関係なくIntelの覇権が続くんじゃないかと予想しています。
Re: (スコア:0)
以前は重荷になっていたx86の命令デコーダーも今やダイに占める割合は数%まで下がってますからね
今でもボトルネックの一つではあるのですが、相対的に影響度は下がってます
Intelもわかっていて、デコーダーがなるだけ働かなくても良いようにいろいろ工夫してますし(sandy bridge以降のuop cache)
>Intelのプロセス技術とか回路技術がすごすぎて
全く同感です。
そろそろIntel以外の全メーカーを周回遅れにしそうな勢いだもんなぁ
Re:x86アーキテクチャから離れる必要がないから (スコア:0)
以前は重荷になっていたx86の命令デコーダーも今やダイに占める割合は数%まで下がってますからね
いまどきのプロセッサはキャッシュがでかいから命令デコード部分が全体の割合として小さくなってるというだけで、複雑なことに変わりはないんじゃないの。
Re:x86アーキテクチャから離れる必要がないから (スコア:1)
x86は命令が可変長で、命令の区切りは先頭からデコードしてみないとわからないという特徴があります
複数命令同時デコードというのはつまるところ総当たりでデコードしてみて正しい結果だけ利用するということになります
(実際はデコードに複数サイクルかけたり、並列にデコードできる組み合わせを制限したりしていますが)
命令デコーダーは非常にビジーなユニットで、かつ結果をほとんど捨ててしまうので、電力的に大きな損失になります
また、同時デコード数を増やすと回路規模は組み合わせ論的に増えていきます