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

最大 16 Core の MIPS64 プロセッサが登場 43

ストーリー by yoosee
太陽は沈まず 部門より

magicalchalk曰く、"Sun UltraSPARC T1 の最大8コアが処理能力的に有効ならばもっとコアを増やせば良いと考えるのも自然なわけで、Cavium Networksという会社からOCTEON Plus CN58XX シリーズという最大 1GHz x 16 Core の MIPS64 プロセッサが登場しました。 インターフェイスとしては 8x Ethernet and/or 2x SPI4.2 networking interfaces、144-bit 800-DDR2 memory controller、暗号アクセラレータ等を On Chip で搭載しています(プレスリリース)。

LAMPサーバとして使うなどの用途が考えられますが、実際にはどのようなサーバ筐体・パッケージで販売されるのか、Linux で使うとして MIPSアーキテクチャを管理できるか、などを考えなくてはいけない気がします。サーバハードウェアはこの先どのように進んでいくのでしょうか?"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • LAMPサーバ? (スコア:4, 参考になる)

    by tmiura (6268) on 2006年10月21日 1時43分 (#1041671) 日記

    用途としてタレコミには「LAMPサーバ」とありますが、 この会社、Cavium Networksってぐらいですから、念頭にあるターゲットはネットワーク関係処理のアクセラレータだとプレスリリースにしっかり書いてありますよね。

    このプロセッサを載せたハーフサイズPCI-Xカード(インテリジェントなマルチギガビットNICに仕立ててある)も出しているようで、ターゲットとして挙げられている処理はネットワーク及びストレージの

    • SSL/IPsec
    • TCP
    • 圧縮・伸長
    • 侵入防御・アンチウイルス

    だそうです。

    もちろんこれらは作った側が想定しているだけで、 一方ではMontaVista LinuxやVxWorksのサポートもあるそうですから頑張ればLAMPサーバにできないこともないでしょうが、基本的には通信関係への組み込みを狙っているわけでしょう(LAMPサーバにアドオンして何かのアクセラレータにするのはもちろんアリですが)。

    プロセッサのデザイン上も、少ない共有キャッシュはデータストリーム(それ自体には再利用性は低い)に対してわりあいと決まった処理をひたすら繰り返すのを想定した割り切りでしょうし、浮動小数点の機能がない辺りも通信がターゲットだからでしょう。

    というか、通信関係を想定するだけでもこのボード、おもちゃとして相当楽しそうですね……ええと、日本での取扱は東京エレクトロンか。

  • by Technobose (6861) on 2006年10月20日 23時45分 (#1041573) 日記
    まだサーバー用途で生き残っているんですね。
    でも、SPARCを持っているサンから、なぜMIPSが出るのか不思議です。いくつものプロセッサのアーキテクチャをサポートできるほどの余力は有るのでしょうか。
    • by hiroc-han (23419) on 2006年10月21日 0時07分 (#1041591)
      SGIの会社更生が終了というニュースが出た途端SUNからMIPSが。
      OSはSOLARIS?。これでサポートがSPARC, Intel, MIPSと増えて、
      かつてのWindows NTの二の舞いにならないと良いのですが。

      でもリンク先を見てもCAVIUMという会社がMIPS64base cpuを
      開発したとあるのですが、SUNの文字は見当たらない(www.sun.comにも)
      ですね。

      SUNが売り出すというニュースソースは?。
      親コメント
      • by Anonymous Coward
        タレコミ文のどこにも、SUNから発売、とは書かれていない。
        何故、SUNを比較に引いたのかは分からない。
        • by Anonymous Coward
          部門名を見れば分かるように、編集者は完全に誤解してます。
    • とりあえず、やってみようって考えがあるのでは?
      わけのわからん執着心でオンリーワンはあほでしゅ。

    • by Anonymous Coward
      組み込みではまだまだ現役ですがな。

      ミップス・テクノロジーズ [www.mips.jp]

      MIPS Technologies [mips.com]
    • by Anonymous Coward
      PlayStationってMIPSアーキテクチャだと思っていたのですが…
    • by Anonymous Coward
      Sunに買収されたCobalt社のサーバが、もともとMIPS互換チップ搭載のLinuxサーバだったので、
      その系譜がついに復活!と言いたいのですが、それはないでしょうねぇ・・・。
    • by Anonymous Coward
      MIPSアーキテクチャであることには、さほど意味はありません。
      アーキテクチャライセンスの取得のみでしょう。
      RMI(Raza Microelectronics, Inc.)にもXLRプロセッサというのがあります。

      http://www.razamicroelectronics.com/products/xlr.htm [razamicroelectronics.com] http://pc.watch.impress.co.jp/docs/2005/0531/spf07.htm [impress.co.jp]

  • by warudakumi (24294) on 2006年10月20日 23時50分 (#1041574) 日記
    リンク先のプレスリリースをざっくり眺めてみましたが、どこにも "Sun" というコトバは見あたらず。

    Sun Microsystems といえば Sparc アーキテクチャー(最近はAMD64も。大昔は68000)だと思うので、どのあたりから *Sun* とつながるのか教えて頂ければ。いや、マジで。
  • by Anonymous Coward on 2006年10月21日 0時05分 (#1041590)
    門外漢なんで直感で書いてるけど
    16コアもあるのにセカンドキャッシュが共有で2MBは
    少なくは無いのでしょうか?
    生粋のRISC CPUならきつそうに思うんだけど
    実際はそんなことは無いのでしょうか?
    • 場所足りなくてそれ以上入れられんのでは?
    • by Anonymous Coward
      L2キャッシュが2MBでは足りないという場合は
      L1キャッシュのヒット率が低いという場合が多いでしょうから、
      おそらく容量より先にL2キャッシュ以降の帯域の方が
      問題になってくるんじゃないですかね?

      つまり、L2キャッシュの容量も帯域も不足していると考えるよりは
      L2キャッシュが2MBで不足するようなアプリケーションは
      もとよりターゲットとしていないと考えた方が納得がいきます。

      そもそもL1命令キャッシュが32Kに対して
      L1データキャッシュが16Kしかないことから
      データより命令を重視していることがわかりますが、
      このL2キャッシュの仕事はどちらかというと
      大きなデータを載せておくこととい
    • キャッシュヒット率は、ある特定のプログラムを使用した時に決まるものだよね。
      キャッシュ容量が十分かどうかは、ヒット率が高いか低いかで判断するべきじゃないのかな。

      結局、どんなアプリケーションが乗るか不明な開発直後だからして、
      とりあえず入れられる分、入れてみたっていうのが真相じゃないのかな。
  • by Anonymous Coward on 2006年10月21日 2時40分 (#1041712)
    と、思ったら、新しいチップなのか。

    以前にandoさんとこで紹介されていた記事を貼っておこう。
    http://news.com.com/Linux+powers+unusual+multicore+machine/2100-7344_3... [com.com]

    主たる使い道はネットワークアプライアンスで、ルータとかファイアウォールとかIDSとかなんでしょうね。
    国内にもMIPS 32個積んでちょーはやいルータ作ってる会社があったような。。。

    • つーか Cisco が MIPS を使い続けている関係で、そういう分野の製品に使用例が多いということ。というのは、たくさん積む関係で、

      1. 消費電力の割に性能が高い。
      2. 消費電力の絶対値が大きくない。
      3. その条件下で、そこそこの性能が出る

      という条件を付けると、MIPS か PowerPC 以外の選択肢はつい少し前まではなかったという理由です。

      親コメント
  • by Anonymous Coward on 2006年10月21日 9時49分 (#1041791)
    コア多いの大変いいのだけれど、かなり賢いコンパイラがないとアプリの性能は出ない。
    組み込みとかにしか恩恵がない製品だと思う。
    • by yzkk (29014) on 2006年10月21日 23時14分 (#1042134)
      別にコンパイラに頼らずとも、必要な処理を適切なコアに割り振るよう
      プログラムできる環境があればいいのではないかな。

      コンパイラで最適化するといっても、現状はコア単位だろうし。それを
      タスク単位で認識して各コアに割り当てる仕事がコンパイラというのも
      納得できないなー。

      つまるところ、マルチコアの性能を引き出すのは、その性質を熟知した
      プログラマの能力だろうよ。コンパイラは個々のプログラムの最適化
      をやってくれれば良いし、どこのコアで何の処理が走っているのか
      コンパイルするまでわからんというのも気持ち悪く無いか?
      親コメント
      • って、プログラマがやるのかよ!!
        OSに任せれば良ぃじゃん。
        #三村ツッコミ風で

        正直、どこのコアで何の処理が走っているのか?なんてことまで、
        プログラマがわからんとイカンというのも気持ち悪くない?
        マルチタスクに分割できるとこは、ガンガン分割して、
        実際のスケジューリングはOSにお任せ。
        これで良いんじゃね?

        生産性とか保守性とかナシで、
        ガンガンに実行効率重視でってことなら、
        なんでもかんでもプログラマが!
        …ってのもアリですけどね。

        • OSの役目でもないような。動いているプログラムから他のスレッドを見ると、別のCPUで動いているように見えるだけで、コンパイラもOSもそちらには影響をおよぼしにくい。しいて言えば共有資源を奪い合わないようにうまく排他制御してやる程度ではないかと。コンパイラが大きな影響を持つのはペアリングが重要なスーパースカラなCPUに対してのみ、OSが大きな意味を持つのは同期プリミティブの操作に対してのみじゃないかと。

          そもそもSMTってのはメモリアクセスのレイテンシを隠蔽するから速くなるんであって、関係のある(つまりメモリアクセスの競合がありうる)スレッドを同時に実行すると効率が下がるはず。だからOSとしてできるのは、むしろ無関係なタスクを投入してやることくらいじゃないかなあ。

          # 一応私は組み込み系の人ですけど、(密結合の)マルチプロセッサシステムなんて触ったこともないですよ orz...

    • by Anonymous Coward
      一般的にサーバが大量のCPU積んだり、大量のCore載せたりするのはプロセスやスレッドを大量に発生させても速度の低下が少なくて済むという恩恵を受けるためじゃないの?
      数値計算サーバのような特殊な分野は別として。
    • by Anonymous Coward
      いわゆる最適化コンパイラががんばるのは命令レベル並列化・性(Instruction Level Parallelism)
      Pentium系だとu-v命令ペアとか uOPにしたときの充填率とか SSExへの変換とか
      MIPSだとソフトウェアパイプラインぐらいしか思いつかないけど

      手続き型言語で書かれたコードからスレッド並列性を自動抽出してくれる最適化コンパイラって聞いたことないですね
      早大の笠原先生のところのマクロタスクスケジューラとかはそういうのできそうな気もしてたんですけどどうなんでしょう

      並列処理命令のある言語用のコンパイラ(HPFとか)は
      だいたいSPMDのコードを想定
  • by Anonymous Coward on 2006年10月21日 14時26分 (#1041960)
    当然、次はSun12個だな。
  • by Anonymous Coward on 2006年10月20日 23時43分 (#1041571)
    Sun から?
  • by Anonymous Coward on 2006年10月20日 23時51分 (#1041577)
    日本語で書けばよかったのに
  • by Anonymous Coward on 2006年10月21日 1時35分 (#1041667)
    > サーバハードウェアはこの先どのように進んでいくのでしょうか
    ハードウェアもそうだけど、ソフトウエアもどう進化していくのでしょうかね。
    ハード側はマルチコア、メニーコアで進化していくと言っても、
    実際には対応するOSやアプリケーションがなければ、 絵に描いた餅状態でしょう。
    サーバーに必要な機能なんかは分散処理しやすいのかもしれませんが、
    メニーコアになって実際にパフォーマンスは上がるの?
    • by Phalacrocoracidae (29780) on 2006年10月21日 12時39分 (#1041903)
      最近流行のVMwareやXenなどの仮想化ソフトウェアにはピッタリ合いそうです>マルチコア。

      個々の仮想環境にCPU割り当てればOK。その上で動くOSはマルチコア対応でなくても大丈夫。

      --
      しないさせない!スルー力
      親コメント
      • by Anonymous Coward
        でもさ、例えばの話だけど2Ghzで動くデュアルコアのCPUと
        クアッドコアのCPUがあって、どちらもコアは同じものだったとして、
        そこに2つのスレッドを走らせたら、やっぱりどちらも処理性能は変わらないような気がするのですよ。
        (そのとき、クアッドコアの2つのコアは遊んでいるのではないかと)
        でも、将来的にはどんな(例えば過去の遺産的な)アプリでも、コア数に応じてパフォーマンスが上がってくれないかなぁ、と夢想するわけですよ。
        そう言った意味で現状でのOSやアプリはそこまで行っていないよね・・・。
        でもサーバー向けの専用アプリとかだったらコア数に応じて実装を変えたりとかしてるのかな・・・。
        • by Phalacrocoracidae (29780) on 2006年10月22日 9時02分 (#1042205)
          > でもさ、例えばの話だけど2Ghzで動くデュアルコアのCPUと
          > クアッドコアのCPUがあって、どちらもコアは同じものだったとして、
          > そこに2つのスレッドを走らせたら、やっぱりどちらも処理性能は変わらないような気がするのですよ。
          > (そのとき、クアッドコアの2つのコアは遊んでいるのではないかと)

          確かにスレッドが2つしか存在しないならそうなりますが、実際問題としてサーバではプロセスやスレッドが何十、何百と動いてるのが普通だと思います。
          例えばApacheで同時に10コネクションの接続があれば、10個のプロセス又はスレッドが実行されるわけで。

          デスクトップでもタスクマネージャで見れば沢山プロセスが起動してますね。それだけでも(多少は)効果があるんじゃないかと。サーバほどではないでしょうが。
          --
          しないさせない!スルー力
          親コメント
        • by Anonymous Coward
          過去の遺産的なアプリなら、今のCPUで動かせば十分速くなってるでしょう。
          そもそも古いアプリだと、アルゴリズムも練れてなかったり少ないメモリで動かすために速度を犠牲にしてたりするんで、無理に高速に動かしてもあまり意味無かったりしますけど。
    • by Anonymous Coward
      メインフレームのあとを追いかけていく
typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

読み込み中...