パスワードを忘れた? アカウント作成
15009 story

Sunでプロセッサ事業が新部門として復活 25

ストーリー by yoosee
まだだ、まだ終わらんよ 部門より

microsparc5 曰く、

数年前に活動を停止し、ひっそりと消えるのではないかと思われていたSun MicrosystemsのSPARC部門だが、Sun のプロセッサ事業新部門として活動を開始するようだ。 Sun のプレスリリース Sun Microsystems Expands Focus on Silicon Design によれば、 新設されたマイクロエレクトロニクス部門では高速ネットワーキング用チップの設計、 次世代マルチスレッドプロセッサなどを、世界のOEM顧客企業に対して提供するとのこと。
SPARC自体が復活すると言う筋書きがあるかどうかはさだかでは無いですが、Solarisといい最近のSunはいろいろ復活させてきてますね。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • T1(コードネームNiagara)は無視ですか。確か正式リリースが2005/11なのですが。
    まあUltraSPARCなのでSPARCとは違うといわれればそれまでですが。

    #もしかして数年前の範疇に1年前も含まれる?
  • by Anonymous Coward on 2007年03月29日 12時00分 (#1133988)
    オープン系では今や何でもIAサーバに走る傾向があるけど、
    本当にIAだけでいいのかと思うときがある。

    どのアーキテクチャでも得手不得手はあるわけだから、
    単一で賄おうとすることもあるまいに。
    • しかし、アーキテクチャ上の得手不得手というのもさほど大きいものではない、
      と言われているし、それに、IAのほうが格段に低廉だというメリットを乗り越えることは
      非常に難しいのでは。

      SPARCはサーバーの汎用プロセッサよりは、高性能通信・ネットワーク・各種産業用システムや
      組込み分野で発展していくべきです。
      親コメント
      • IA だと、エントリーが安くて、性能が必要なら台数を増やせばよくて、管理の手順はほぼ全ての管理者が知っている、その点は断然強いですよね。

        ただ、アーキテクチャというより実装の面で気になることはあります。Sun の Niaraga シリーズがしている提案は、デスクトップ向け最良の CPU を多数使用しても好ましいサーバにはならない -少なくとも 2007 年現在では-、ということだと考えています。

        IA サーバは、多数導入しても安いし、管理者も知り尽くしていて安心感がありますが、実際に多数導入したらサーバ室はサウナになってしまいます。

        コアが遅くてもスレッド数を増やせばトランザクション数は上がるし消費電力は少なくてすむ、だからコアを速くすることは弊害のほうがが大きい、という提案は、筋が通っていても、実装できるのはサーバ専用 CPU だけだと思うのです。そして Niagara シリーズはそれをやりました。

        IA で、命令セットは同一でも、デスクトップ向けとサーバ向けで違うコアが提供される日は来るのか来ないのか気になっています。

        親コメント
    • > どのアーキテクチャでも得手不得手はあるわけだから、

      得手不得手ってそんなにあるのかなぁ という印象が…

      Intel Architecture向けの環境 と Solaris の比較を
      アーキテクチャ出自のものだとして認識されてるんじゃないかと危惧

      たとえば Solaris の安定性と SPARC+周辺チップの安定性 を区別できてないとか…
      至ってはSolarisの標準的なパッケージ管理のダサさとPCサーバ向けOSのパッケージ管理のスマートさがチップのイメージを左右しているとか

      かつて Microsofot Windows と MacOS X の違いが
      Intel Architecture と PowerPC Platform の違いに因るものだという
      謎の主張がまかり通っていたMac系の雑誌とか多かったし…
      (で Intel CoreDuo になってなにか変わったのかよ? と)
      • > かつて Microsofot Windows と MacOS X の違いが
        > 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に選択の余地は無かった)のではないかという意見の人もいらっしゃいます。
        言われてみると、思い当たるフシがあります。
        親コメント
      • ハードの性能だけでなく、上で走るOSの性能、その上で走るアプリの使い勝手、ライブラリの充実度、リファレンスやマニュアルの親切さ、サポートの手厚さ、トータルコスト、技術者の頭数、などなど、いろんな要素が絡んでの評価になるのでは?
      • >かつて Microsofot Windows と MacOS X の違いが
        >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
    • んー、IA32系の石は、基本が20年前のCISCである8086でそこにどんどん拡張していったのを高速に処理するために内部処理をRISCっぽくしているという感じで、内部構造が複雑ですからね。
      実際組み込みでPPCとかMIPSコアのサードパーティの石の低レベル部分とかをハイエンドアプリ搭載の基板向けに弄っていましたが、クロック対処理能力比でいうとIA32ベースよりも数段上でした(って、基本となるチップの世代が1世代は違いますからね…)

      まぁ、そういう事を考えると、SunがRISC(ですよね?)MPU開発事業を再開したというのは、ハイパフォーマンス市場に対応するために高クロック化しすぎて熱の面で厳しくなりつつあるけどIA系の次にユーザエンドでは使われているPPC系に対抗可能なニーズが確実にある。と読んだのでしょうね。

      # でも、「OSもアプリもJavaで書け」とかなったりしたら(^_^;
      • by Anonymous Coward on 2007年03月29日 15時04分 (#1134093)
        CISCだのRISCだのって化石みたいな話ですね。
        いまどきこんな投稿をするひとが存在することにびっくりです。
        親コメント
      • RISCって、どんなに頑張っても、1サイクルに1命令しかフェッチできませんけど、
        現在のx86は、複数のRISC命令を1つのCISC命令に「圧縮して」主記憶においてる
        ようなもんだから、インストラクションを演算コアに流し込む速度で、絶対的な
        優位があると思います。
        • あー、単純な速度の事を言ってるのではありません。

          クロック対処理能力比の問題もありますが、どちらかというとCISC命令からRISC命令にデコードしている関連で色々とややこしい処理なんかも行わなくてはいけなくなって、1コアあたりのトランジスタ数がRISCで性能ー消費電力の比率がよろしくない(CISCでも特にx86_64系のMPUなんかは最近は製造プロセスの微細化やロジックの最適化でかなり改善はされていますが…)あたりが主眼のつもりで書いたのですが…

          親コメント
          • 組み込み系でx86系が弱いのは単にintelが注力していないからでしょう。
            確かにx86のデコーダは複雑ですが、1クロック1,2命令のデコーダであれば最近(ここ十年の)プロセスでは他の命令セットと比べても微妙な差にしかならないはずです。
            そして、デコーダを抜けてしまえば命令セットがRISC系でもCISC系でも大して変わらない処理になります。
        • そのRISCやCISCの定義はどこから出てきたものですか?
          • もともとの、RISCプロセッサの特徴ってこんなのですよね。

            基本思想は
            ・利用頻度の少ない高機能命令の実装をばっさりカット(これが縮小命令セットと言われる理由)
            ・命令が途中でつっかえたりしない効率的なパイプライン運用ができるハードを作る
            ・そのために必要なチューニング等の難しい部分はコンパイラーにおまかせ

            で、

            実際の実装は
            ・単純な命令しか用意しないかわりに、1マシンサイクルで必ず1命令を実行させ、限界までCPIを稼ぐ
            ・命令を処理しやすいように1命令1ワードに納まる固定長の命令セットにする(即値も命令コード内に含める)
            ・マイクロコードによる複雑な命令解析は諦め、直接ワイヤードロジックで制御回路を組んで高クロックで実行する
             (もともとマイクロコードを入れていたはずのメモリ部分は巨大なレジスタセットとキャッシュメモリに充てる)
            ・演算操作はレジスタ間のみに限定、メインメモリは遅くてアクセスが間に合わないのでオペランドにしない
            ・メモリとレジスタ間のデータ転送はロード&ストア命令だけに限定、アドレッシングモードは最小限にする
            ・必要なら、パイプラインをストールさせないために分岐予測や遅延分岐を用いる
            という感じでしょうか。

            現在RISCだと自称するプロセッサのほとんどが、このルールのどれかに違反していますが…。
            PowerPCなんて、物凄く高機能な命令が「これでもか!」というほど用意されてますし。
            組み込み向けRISCプロセッサも多くが16/32Bit可変長命令をサポートしていたりするわけで。
            逆に、単純命令のワイヤードロジック制御による実行なんかは、i486あたりからx86系プロセッサも採用していて、
            CISCプロセッサだとは言われますが、キャッシュにある単純命令を1サイクルで実行可能だったはず。

            メーカーが自社のチップをRISCプロセッサであるとカタログに謳っていたとしても、ほとんどのケースが
            「RISC風味がたくさん入ったアーキテクチャです」という意味にすぎないと言えなくもない。
            結局、「RISCプロセッサです」と書くと、カスタマにも「ワークステーション等に使われているような
            高性能なCPU設計を取り入れた製品だ」と思ってもらえるからでしょうか。セールストークとしては効果的だよね。

            RISCは1サイクルに1命令しかFetchできないって話がありましたが、VLIWなんかは多数の命令を1命令に
            パックしたものなので、等価的に多数の命令を同時実行していると思います。ですが、この方式は
            実行ユニットに命令を埋めていくのが大変らしいとかで。
            例えば、TransmetaのCrusoeは、VLIWチップ本来の命令セットである「ネイティブモード」で動かすと、
            同じ事やらせてもコードモーフィングで変換して実行する時よりも性能が落ちるそうで。
            VLIWは命令が大きくてFetchするのにも大きなバス帯域を喰いますから、それが結構重い負担になるようです。

            となると、CISC的な高機能命令セットでバスに負担をかけないコンパクトな命令列をCPUへ読み込み、
            命令デコーダで複数の内部RISC命令に分割して実行ってのはバス帯域を圧迫しないという点で、
            あながち間違ったやり方ではないのかもしれません。Pentium4なんか内部命令に変換したものを
            そのままトレースキャッシュとしてまるごと保持して次からデコード抜きで実行したりしてますし。

            Athlonみたいに演算ユニットが9つもあって、それをみんなVLIWで制御するとなると、VLIW方式を採用して、
            全てに毎回命令を割り当てて完全な制御下に置くことを考えると、とんでもない長さの命令が必要になりますから、
            結局、今のような実装でいいのかなという気もします。
            親コメント
            • 例えば、TransmetaのCrusoeは、VLIWチップ本来の命令セットである「ネイティブモード」で動かすと、
              同じ事やらせてもコードモーフィングで変換して実行する時よりも性能が落ちるそうで。
              VLIWは命令が大きくてFetchするのにも大きなバス帯域を喰いますから、それが結構重い負担になるようです。

              その話をもう少し聞かせてください。というか、私が思っていたのとアーキテクチャが違うので戸惑っています。

              私が思っていたのは、Crusoe には VLIW 命令セットしかなくて、VLIW 命令セットで実装されたインタプリタが動いている時間帯と VLIW 命令セットにコンパイルされたコードが動いている時間帯があるという動作でした。つまり、いつでも VLIW 命令を Fetch している動作だと思っていました。

              VLIW 命令の中を埋められないのはそうだと聞きましたし、コードモーフィングは実行時情報を使って最適化(そもそも計算をしない、等)もできる可能性もあると聞きます。でも命令セットが2系統あるという話はちょっと。

              親コメント
              • 別にアーキテクチャは違わないのじゃないかな。
                仕組み的にコードモーフィングでVLIMのFetchはキャッシュの効率がすごく良くなると思うので主記憶から全てを持ってくるのに比べたら、それなりの違いが出てもおかしくない。
                命令セットが2系統あるというよりも、コードモーフィングの実行を前提にした特別な仕組み(特権命令とか割り込み)があるんじゃないでしょうか。
                親コメント
        • SuperHシリーズやARMのThumbモードはRISCではないという主張ですか?
typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...