Sunでプロセッサ事業が新部門として復活 25
ストーリー by yoosee
まだだ、まだ終わらんよ 部門より
まだだ、まだ終わらんよ 部門より
microsparc5 曰く、
数年前に活動を停止し、ひっそりと消えるのではないかと思われていたSun MicrosystemsのSPARC部門だが、Sun のプロセッサ事業新部門として活動を開始するようだ。 Sun のプレスリリース Sun Microsystems Expands Focus on Silicon Design によれば、 新設されたマイクロエレクトロニクス部門では高速ネットワーキング用チップの設計、 次世代マルチスレッドプロセッサなどを、世界のOEM顧客企業に対して提供するとのこと。
SPARC自体が復活すると言う筋書きがあるかどうかはさだかでは無いですが、Solarisといい最近のSunはいろいろ復活させてきてますね。
「数年前に活動を停止し」って (スコア:2, 参考になる)
まあUltraSPARCなのでSPARCとは違うといわれればそれまでですが。
#もしかして数年前の範疇に1年前も含まれる?
Re:「数年前に活動を停止し」って (スコア:4, 参考になる)
Re:「数年前に活動を停止し」って (スコア:1)
プロセッサですから (スコア:1, おもしろおかしい)
IAとSPARCしか触ったことのない者の戯言 (スコア:2, すばらしい洞察)
本当にIAだけでいいのかと思うときがある。
どのアーキテクチャでも得手不得手はあるわけだから、
単一で賄おうとすることもあるまいに。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1)
と言われているし、それに、IAのほうが格段に低廉だというメリットを乗り越えることは
非常に難しいのでは。
SPARCはサーバーの汎用プロセッサよりは、高性能通信・ネットワーク・各種産業用システムや
組込み分野で発展していくべきです。
デスクトップとサーバの CPU の実装が別になる日は再び来るか (スコア:3, 興味深い)
IA だと、エントリーが安くて、性能が必要なら台数を増やせばよくて、管理の手順はほぼ全ての管理者が知っている、その点は断然強いですよね。
ただ、アーキテクチャというより実装の面で気になることはあります。Sun の Niaraga シリーズがしている提案は、デスクトップ向け最良の CPU を多数使用しても好ましいサーバにはならない -少なくとも 2007 年現在では-、ということだと考えています。
IA サーバは、多数導入しても安いし、管理者も知り尽くしていて安心感がありますが、実際に多数導入したらサーバ室はサウナになってしまいます。
コアが遅くてもスレッド数を増やせばトランザクション数は上がるし消費電力は少なくてすむ、だからコアを速くすることは弊害のほうがが大きい、という提案は、筋が通っていても、実装できるのはサーバ専用 CPU だけだと思うのです。そして Niagara シリーズはそれをやりました。
IA で、命令セットは同一でも、デスクトップ向けとサーバ向けで違うコアが提供される日は来るのか来ないのか気になっています。
Re:デスクトップとサーバの CPU の実装が別になる日は再び来るか (スコア:0)
ろくに管理されていないWindowsサーバーもちまたにあふれてるし。
Re:デスクトップとサーバの CPU の実装が別になる日は再び来るか (スコア:1)
ラック面積や電源容量、管理コストを考えるとSPARCで組んだ方が良いと思う事は多い
#パッチあてに1週間潰す事に疑問を持っている人
Re:デスクトップとサーバの CPU の実装が別になる日は再び来るか (スコア:0)
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
得手不得手ってそんなにあるのかなぁ という印象が…
Intel Architecture向けの環境 と Solaris の比較を
アーキテクチャ出自のものだとして認識されてるんじゃないかと危惧
たとえば Solaris の安定性と SPARC+周辺チップの安定性 を区別できてないとか…
至ってはSolarisの標準的なパッケージ管理のダサさとPCサーバ向けOSのパッケージ管理のスマートさがチップのイメージを左右しているとか
かつて Microsofot Windows と MacOS X の違いが
Intel Architecture と PowerPC Platform の違いに因るものだという
謎の主張がまかり通っていたMac系の雑誌とか多かったし…
（で Intel CoreDuo になってなにか変わったのかよ? と）
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1)
> Intel Architecture と PowerPC Platform の違いに因るものだという
> 謎の主張がまかり通っていたMac系の雑誌とか多かったし…
もっと古い80286(1982)と68020(1984)の時代ならそうも言ってられなかったと思いますが、
MacOSXのベースになったとされるNEXTSTEPは68040でも、AT互換機上で動いてましたから、
移植できることはちょっと考えればわかったと思うんですけどね。
エンディアンの違いは、それほど大きなものなのかな？
まぁでも、機能的にサポートしてない演算があれば、他のCPUと比べて得手、不得手は出ると思いますよ。
AltiVec(VelocityEngine)みたいなモノはCPUに装備されてないと使えませんし、以前に聞いたPPCがx86より速い理由は、
「これを使えばPhotoshopのフィルタ処理が超高速で終了するから…」という理由だったと思います。
Appleは結構ビジネスの分野で身勝手な行動を取るので(MacOS互換機潰しとか)、実はIBMに見捨てられた結果、
Intelを選ばざるを得なかった(Appleに選択の余地は無かった)のではないかという意見の人もいらっしゃいます。
言われてみると、思い当たるフシがあります。
アーキテクチャの評価ってそういうもんでは？ (スコア:0)
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
>Intel Architecture と PowerPC Platform の違いに因るものだという
>謎の主張がまかり通っていたMac系の雑誌とか多かったし…
Pentium IIとPowerPC G3の時代は、バックサイドキャッシュによる差が
はっきりとあったし、Pentium III(Pentium 4初期)とPowerPC G4の時代は
AltiVecの性能の高さはダントツだった。Pentium 4とPowerPC G5の時代は
メモリバンドワイズとメモリの搭載可能量という違いも加わった。
Core 2 Duoでは、AltiVecに相当するIntel Anvanced Digital Media Boost
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
実際組み込みでPPCとかMIPSコアのサードパーティの石の低レベル部分とかをハイエンドアプリ搭載の基板向けに弄っていましたが、クロック対処理能力比でいうとIA32ベースよりも数段上でした（って、基本となるチップの世代が１世代は違いますからね…）
まぁ、そういう事を考えると、SunがRISC（ですよね？）MPU開発事業を再開したというのは、ハイパフォーマンス市場に対応するために高クロック化しすぎて熱の面で厳しくなりつつあるけどIA系の次にユーザエンドでは使われているPPC系に対抗可能なニーズが確実にある。と読んだのでしょうね。
# でも、「OSもアプリもJavaで書け」とかなったりしたら(^_^;
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1, すばらしい洞察)
いまどきこんな投稿をするひとが存在することにびっくりです。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1, おもしろおかしい)
A. CISCはRISC的間違いを犯し、RISCはCISC的間違いを犯すものなのです。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
現在のx86は、複数のRISC命令を1つのCISC命令に「圧縮して」主記憶においてる
ようなもんだから、インストラクションを演算コアに流し込む速度で、絶対的な
優位があると思います。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:1)
クロック対処理能力比の問題もありますが、どちらかというとCISC命令からRISC命令にデコードしている関連で色々とややこしい処理なんかも行わなくてはいけなくなって、１コアあたりのトランジスタ数がRISCで性能ー消費電力の比率がよろしくない（CISCでも特にx86_64系のMPUなんかは最近は製造プロセスの微細化やロジックの最適化でかなり改善はされていますが…）あたりが主眼のつもりで書いたのですが…
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
確かにx86のデコーダは複雑ですが、1クロック1,2命令のデコーダであれば最近(ここ十年の)プロセスでは他の命令セットと比べても微妙な差にしかならないはずです。
そして、デコーダを抜けてしまえば命令セットがRISC系でもCISC系でも大して変わらない処理になります。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:3, 興味深い)
基本思想は
・利用頻度の少ない高機能命令の実装をばっさりカット（これが縮小命令セットと言われる理由）
・命令が途中でつっかえたりしない効率的なパイプライン運用ができるハードを作る
・そのために必要なチューニング等の難しい部分はコンパイラーにおまかせ
で、
実際の実装は
・単純な命令しか用意しないかわりに、１マシンサイクルで必ず１命令を実行させ、限界までCPIを稼ぐ
・命令を処理しやすいように１命令１ワードに納まる固定長の命令セットにする（即値も命令コード内に含める）
・マイクロコードによる複雑な命令解析は諦め、直接ワイヤードロジックで制御回路を組んで高クロックで実行する
（もともとマイクロコードを入れていたはずのメモリ部分は巨大なレジスタセットとキャッシュメモリに充てる）
・演算操作はレジスタ間のみに限定、メインメモリは遅くてアクセスが間に合わないのでオペランドにしない
・メモリとレジスタ間のデータ転送はロード＆ストア命令だけに限定、アドレッシングモードは最小限にする
・必要なら、パイプラインをストールさせないために分岐予測や遅延分岐を用いる
という感じでしょうか。
現在ＲＩＳＣだと自称するプロセッサのほとんどが、このルールのどれかに違反していますが…。
PowerPCなんて、物凄く高機能な命令が「これでもか！」というほど用意されてますし。
組み込み向けRISCプロセッサも多くが16/32Bit可変長命令をサポートしていたりするわけで。
逆に、単純命令のワイヤードロジック制御による実行なんかは、i486あたりからx86系プロセッサも採用していて、
CISCプロセッサだとは言われますが、キャッシュにある単純命令を１サイクルで実行可能だったはず。
メーカーが自社のチップをRISCプロセッサであるとカタログに謳っていたとしても、ほとんどのケースが
「ＲＩＳＣ風味がたくさん入ったアーキテクチャです」という意味にすぎないと言えなくもない。
結局、「RISCプロセッサです」と書くと、カスタマにも「ワークステーション等に使われているような
高性能なCPU設計を取り入れた製品だ」と思ってもらえるからでしょうか。セールストークとしては効果的だよね。
RISCは１サイクルに１命令しかFetchできないって話がありましたが、VLIWなんかは多数の命令を１命令に
パックしたものなので、等価的に多数の命令を同時実行していると思います。ですが、この方式は
実行ユニットに命令を埋めていくのが大変らしいとかで。
例えば、TransmetaのCrusoeは、VLIWチップ本来の命令セットである「ネイティブモード」で動かすと、
同じ事やらせてもコードモーフィングで変換して実行する時よりも性能が落ちるそうで。
VLIWは命令が大きくてFetchするのにも大きなバス帯域を喰いますから、それが結構重い負担になるようです。
となると、CISC的な高機能命令セットでバスに負担をかけないコンパクトな命令列をCPUへ読み込み、
命令デコーダで複数の内部RISC命令に分割して実行ってのはバス帯域を圧迫しないという点で、
あながち間違ったやり方ではないのかもしれません。Pentium4なんか内部命令に変換したものを
そのままトレースキャッシュとしてまるごと保持して次からデコード抜きで実行したりしてますし。
Athlonみたいに演算ユニットが９つもあって、それをみんなVLIWで制御するとなると、VLIW方式を採用して、
全てに毎回命令を割り当てて完全な制御下に置くことを考えると、とんでもない長さの命令が必要になりますから、
結局、今のような実装でいいのかなという気もします。
オフトピ: Crusoe の話をもう少し聞かせて (スコア:2)
その話をもう少し聞かせてください。というか、私が思っていたのとアーキテクチャが違うので戸惑っています。
私が思っていたのは、Crusoe には VLIW 命令セットしかなくて、VLIW 命令セットで実装されたインタプリタが動いている時間帯と VLIW 命令セットにコンパイルされたコードが動いている時間帯があるという動作でした。つまり、いつでも VLIW 命令を Fetch している動作だと思っていました。
VLIW 命令の中を埋められないのはそうだと聞きましたし、コードモーフィングは実行時情報を使って最適化(そもそも計算をしない、等)もできる可能性もあると聞きます。でも命令セットが2系統あるという話はちょっと。
Re:オフトピ: Crusoe の話をもう少し聞かせて (スコア:1)
仕組み的にコードモーフィングでVLIMのFetchはキャッシュの効率がすごく良くなると思うので主記憶から全てを持ってくるのに比べたら、それなりの違いが出てもおかしくない。
命令セットが2系統あるというよりも、コードモーフィングの実行を前提にした特別な仕組み(特権命令とか割り込み)があるんじゃないでしょうか。
Re:IAとSPARCしか触ったことのない者の戯言 (スコア:0)