- PR -

RISCの敗因、CISCの勝因

1
投稿者投稿内容
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2002-08-19 18:36
この件名の記事ですが,いくつか重要な論点が抜けてるように思います.

1,古典的CISCはともかく,最近のCISCはRISCをラップしたもの.
高速化技術や内部の設計はRISCそのもの.古典的CISCはほとんど
全滅している.

2,クロックと動作速度は必ずしも関係ない.特にPentium4の
20段パイプラインは反則に近く,クロックほどには性能は高くない.

3,X86の最大の長所は,Windowsが動くこと.CRISCはWindowsによる
市場独占に対する苦肉の策という感が強い.もし,WindowsNTが
マルチプラットフォームを実現していたなら,今ごろはIntelも
CISCから撤退していたかもしれない.(事実,組込み用としては
IntelもARMをライセンスしている.)

4,X86はCISCアーキテクチャであり続けるために,回路規模や発熱,
さらにはコストの点で不利になる.組み込みでRISC全盛である大きな
理由がこれ.
ron
常連さん
会議室デビュー日: 2002/08/19
投稿数: 46
投稿日時: 2002-08-19 19:58
はじめて投稿させてもらいます。
私も「RISCの敗因、CISCの勝因」は読んだのですが、
いくつか悪夢を統べるものさんと意見が異なるところがあるので、
投稿させてください。

>1,古典的CISCはともかく,最近のCISCはRISCをラップしたもの.
>高速化技術や内部の設計はRISCそのもの.古典的CISCはほとんど
>全滅している.
これは私も悪夢を統べるものさんのいう通りだと思います。


>2,クロックと動作速度は必ずしも関係ない.特にPentium4の
>20段パイプラインは反則に近く,クロックほどには性能は高くない.
 クロックと動作速度が必ずしも関係ないことと、Pentium4がクロックほど
性能が高くないことには同意しますが、20段パイプラインが反則というのはどうでしょうか?
たしかにパイプラインが深いので、クロックほど性能は高くないですが、
その代わりに高いクロックを実現することで、高い性能を実現しているので、
単に設計思想の違いだと思います。
でも私も個人的には、Pentium4のアーキテクチャは嫌いです。


>3,X86の最大の長所は,Windowsが動くこと.CRISCはWindowsによる
>市場独占に対する苦肉の策という感が強い.もし,WindowsNTが
>マルチプラットフォームを実現していたなら,今ごろはIntelも
>CISCから撤退していたかもしれない.(事実,組込み用としては
>IntelもARMをライセンスしている.)
 WindowsNT4.0までは、MIPS、ALPHA等がサポートしていたので、
一応マルチプラットフォームが実現していたと思うのですが、
既存のバイナリアプリケーションの互換性および流通の問題で、
結局X86のWindowsNTが残ったのでしょう。
結局それが真のマルチプラットフォームが実現しなかったということなのかも
知れませんが。
 IntelのRISCへの対応策はARMではなく、むしろEPIC(VLIW)アーキテクチャの
Itaniumだと思います。


>4,X86はCISCアーキテクチャであり続けるために,回路規模や発熱,
>さらにはコストの点で不利になる.組み込みでRISC全盛である大きな
>理由がこれ.
 これもその通りだと思います。
ですが、今は元気の無いCrusoeなどのアプローチも、組み込み向けのRISCチップ
がJavaをサポートしたり、マルチメディア命令をサポートしたりすることで、
複雑化するに伴って、普及の目が出てくるかも知れないですね。
 たしかTransmetaの人も、その気になれば世界最高速のJavaチップを作れる
といっていたので。
まあ今のTransmetaの現状を考えると無理でしょうけど。
そうなるとおもしろいかな。

H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2002-08-19 20:08
そうですねぇ。個人的にはRISCは負けたわけではないと思います。組み込みの方がマーケットサイズでは大きいと聞きました。マーケットの規模から言えばRISCの方が有望かもしれない。

> 2,クロックと動作速度は必ずしも関係ない.特にPentium4の
> 20段パイプラインは反則に近く,クロックほどには性能は高くない.
確かに。パイプライン段数を増やせばクロックがあがるのは当然ですけど、パイプライン段数が多いからといって性能がよくなるとは言えませんからね。(特に予測が外れた場合のペナルティは大きくなります)

> いくつか重要な論点が抜けてるように思います.
そうそう、RISCが厳しかったのはコンパイラの発展が弱かったからというのも忘れてはいけないと思います。やっかいな所は全部コンパイラに押し付けるRISCアーキテクチャでのコンパイラは要ですから。昔と違って、コンパイラ技術も発展してきているので、これからに期待しています。
takubon
常連さん
会議室デビュー日: 2001/11/05
投稿数: 38
投稿日時: 2002-08-20 08:54
引用:

悪夢を統べるものさんの書き込み (2002-08-19 18:36) より:

1,古典的CISCはともかく,最近のCISCはRISCをラップしたもの.
高速化技術や内部の設計はRISCそのもの.古典的CISCはほとんど
全滅している.




この部分は同感です。ただ、私自身は未だにZ80のプログラム
を書いたりしています。しかもアセンブラ。いい加減勘弁してほ
しいです。

 いつも思うのですが、たとえばAthlonXPプロセッサのX86命令
を内部命令に変換する部分を取り払って、内部命令を直接読み込
んで実行するように改造すると、爆速プロセッサになるんでしょ
うかね?いつもAMDが試してくれないかなぁと思います。

 後、PowerPCプロセッサがX86互換プロセッサほどクロック周波
数があがらないのは、単に開発にかけるお金が少ないからだと思
うのは私だけでしょうか?

[ メッセージ編集済み 編集者: takubon 編集日時 2002-08-20 09:09 ]
ron
常連さん
会議室デビュー日: 2002/08/19
投稿数: 46
投稿日時: 2002-08-20 15:27
引用:
--------------------------------------------------------------------------------

 いつも思うのですが、たとえばAthlonXPプロセッサのX86命令
を内部命令に変換する部分を取り払って、内部命令を直接読み込
んで実行するように改造すると、爆速プロセッサになるんでしょ
うかね?いつもAMDが試してくれないかなぁと思います。 --------------------------------------------------------------------------------

 X86命令を変換する部分をとりはらって直接内部命令を実行するとなると、
通常のRISCプロセッサとあまり内部的に変わらないので、クロックあたりの実行速度は、
そこらへんが参考値になるのかな。
 Athlonのアーキテクトは旧DEC出身が多いので、Alphaあたりで
比較しても、爆速プロセッサとまではいかないでしょうね。

引用:
--------------------------------------------------------------------------------

 後、PowerPCプロセッサがX86互換プロセッサほどクロック周波
数があがらないのは、単に開発にかけるお金が少ないからだと思
うのは私だけでしょうか?
--------------------------------------------------------------------------------
 たしかに出荷数がけた違いなので、お金のせいかも。
IBMは組み込み向けとサーバ向けのPOWER4には力を入れてるけど、
デスクトップ用は、イリジウムで多額の負債を抱えたモトローラだし。
 まあPowerPC G4は、Pentium4よりはるかに高機能なマルチメディア命令Altivec
を実装したせいで、クロックをあげにくいと前聞いたことがあります。
(Altivec:128ビットレジスタ 32本、SSE2:128ビットレジスタ 8本)


takubon
常連さん
会議室デビュー日: 2001/11/05
投稿数: 38
投稿日時: 2002-08-21 16:18
引用:

ronさんの書き込み (2002-08-20 15:27) より:

 X86命令を変換する部分をとりはらって直接内部命令を実行するとなると、
通常のRISCプロセッサとあまり内部的に変わらないので、クロックあたりの実行速度は、
そこらへんが参考値になるのかな。
 Athlonのアーキテクトは旧DEC出身が多いので、Alphaあたりで
比較しても、爆速プロセッサとまではいかないでしょうね。




 x86命令を内部命令に変換してから実行する仕組みの
為に実行ユニットのIPCが低いですよね。これを、直接
内部命令を実行できるようにするとIPCを今以上にあげ
る事ができるだろうから、かなり高速になるんじゃな
いかと推測していました。まあ、コンパイラ次第になる
んですが・・・。アセンブラで書けば、絶対高速になる
んですけどね。

 TransmetaのCrusoeは、CMSをのぞいて内部VLIW命令を
直接実行するようにしても、ほとんど実効速度が変わら
ないってTransmetaの人が主張しているのを何処かで読
んだ事があります。

 しかし、Transmetaは大丈夫ですかね。もうすぐIntel
のBaniasがでるし、そうなったらつぶれちゃうんじゃな
いかと心配です。Transmeta自体は心配してないんです
が、Linusが・・・。
1

スキルアップ/キャリアアップ(JOB@IT)