最大 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, 参考になる)
用途としてタレコミには「LAMPサーバ」とありますが、 この会社、Cavium Networksってぐらいですから、念頭にあるターゲットはネットワーク関係処理のアクセラレータだとプレスリリースにしっかり書いてありますよね。
このプロセッサを載せたハーフサイズPCI-Xカード(インテリジェントなマルチギガビットNICに仕立ててある)も出しているようで、ターゲットとして挙げられている処理はネットワーク及びストレージの
だそうです。
もちろんこれらは作った側が想定しているだけで、 一方ではMontaVista LinuxやVxWorksのサポートもあるそうですから頑張ればLAMPサーバにできないこともないでしょうが、基本的には通信関係への組み込みを狙っているわけでしょう(LAMPサーバにアドオンして何かのアクセラレータにするのはもちろんアリですが)。
プロセッサのデザイン上も、少ない共有キャッシュはデータストリーム(それ自体には再利用性は低い)に対してわりあいと決まった処理をひたすら繰り返すのを想定した割り切りでしょうし、浮動小数点の機能がない辺りも通信がターゲットだからでしょう。
というか、通信関係を想定するだけでもこのボード、おもちゃとして相当楽しそうですね……ええと、日本での取扱は東京エレクトロンか。
Re:LAMPサーバ? (スコア:0)
Re:LAMPサーバ? (スコア:0)
Re:LAMPサーバ? (スコア:1)
いや、いいんじゃないですか。 かなりマッチングよさそうな気がします。
MIPSって (スコア:1)
でも、SPARCを持っているサンから、なぜMIPSが出るのか不思議です。いくつものプロセッサのアーキテクチャをサポートできるほどの余力は有るのでしょうか。
Re:MIPSって (スコア:1)
OSはSOLARIS?。これでサポートがSPARC, Intel, MIPSと増えて、
かつてのWindows NTの二の舞いにならないと良いのですが。
でもリンク先を見てもCAVIUMという会社がMIPS64base cpuを
開発したとあるのですが、SUNの文字は見当たらない(www.sun.comにも)
ですね。
SUNが売り出すというニュースソースは?。
Re:MIPSって (スコア:0)
何故、SUNを比較に引いたのかは分からない。
Re:MIPSって (スコア:0)
とりあえず・・・・ (スコア:0)
わけのわからん執着心でオンリーワンはあほでしゅ。
Re:MIPSって (スコア:0)
ミップス・テクノロジーズ [www.mips.jp]
MIPS Technologies [mips.com]
Re:MIPSって (スコア:0)
Re:MIPSって (スコア:0)
その系譜がついに復活!と言いたいのですが、それはないでしょうねぇ・・・。
RMIのXLRも (スコア:0)
アーキテクチャライセンスの取得のみでしょう。
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]
何故 "Sun" ? (スコア:1)
Sun Microsystems といえば Sparc アーキテクチャー(最近はAMD64も。大昔は68000)だと思うので、どのあたりから *Sun* とつながるのか教えて頂ければ。いや、マジで。
セクションも部門名も (スコア:5, すばらしい洞察)
セクションがSunなのもそうですが、部門名を見ても編集者がすっかりSunの話題だと信じ込んでいるふしが伺えます。
編集者は今回のタレコミをちゃんと読んだのでしょうか?
Re:セクションも部門名も (スコア:2, すばらしい洞察)
Re:何故 "Sun" ? (スコア:2, 参考になる)
http://www.caviumnetworks.com/OCTEON-Plus_CN58XX.html [caviumnetworks.com]
Re:何故 "Sun" ? (スコア:2)
たぶんコア数だけ (スコア:1)
SunのSPARCは8コアである。ところがMIPSは16コアで対抗だ!どうだ!
でもこれをもって Sunつながり苦しいんじゃないかな。
MIYAZAKI Yasushi
Re:たぶんコア数だけ (スコア:1)
SPARC T1 [sun.com]は8Coreですが同時実行スレッドは32ですので、
単純に16Coreが優れていると断ずるのも難しいですし。
人生は七転び八起き、一日は早寝早起き
素人にはアンバランスに見える (スコア:1, 興味深い)
16コアもあるのにセカンドキャッシュが共有で2MBは
少なくは無いのでしょうか?
生粋のRISC CPUならきつそうに思うんだけど
実際はそんなことは無いのでしょうか?
Re:素人にはアンバランスに見える (スコア:0)
16コアもあれば… (スコア:0)
L1キャッシュのヒット率が低いという場合が多いでしょうから、
おそらく容量より先にL2キャッシュ以降の帯域の方が
問題になってくるんじゃないですかね?
つまり、L2キャッシュの容量も帯域も不足していると考えるよりは
L2キャッシュが2MBで不足するようなアプリケーションは
もとよりターゲットとしていないと考えた方が納得がいきます。
そもそもL1命令キャッシュが32Kに対して
L1データキャッシュが16Kしかないことから
データより命令を重視していることがわかりますが、
このL2キャッシュの仕事はどちらかというと
大きなデータを載せておくこととい
帯に短し、襷に長し (スコア:0)
キャッシュ容量が十分かどうかは、ヒット率が高いか低いかで判断するべきじゃないのかな。
結局、どんなアプリケーションが乗るか不明な開発直後だからして、
とりあえず入れられる分、入れてみたっていうのが真相じゃないのかな。
なんでまた2ヶ月も前の話題なのだ (スコア:1, 参考になる)
以前にandoさんとこで紹介されていた記事を貼っておこう。
http://news.com.com/Linux+powers+unusual+multicore+machine/2100-7344_3... [com.com]
主たる使い道はネットワークアプライアンスで、ルータとかファイアウォールとかIDSとかなんでしょうね。
国内にもMIPS 32個積んでちょーはやいルータ作ってる会社があったような。。。
Re:なんでまた2ヶ月も前の話題なのだ (スコア:1)
という条件を付けると、MIPS か PowerPC 以外の選択肢はつい少し前まではなかったという理由です。
コンパイラは? (スコア:1, 興味深い)
組み込みとかにしか恩恵がない製品だと思う。
Re:コンパイラは? (スコア:1)
プログラムできる環境があればいいのではないかな。
コンパイラで最適化するといっても、現状はコア単位だろうし。それを
タスク単位で認識して各コアに割り当てる仕事がコンパイラというのも
納得できないなー。
つまるところ、マルチコアの性能を引き出すのは、その性質を熟知した
プログラマの能力だろうよ。コンパイラは個々のプログラムの最適化
をやってくれれば良いし、どこのコアで何の処理が走っているのか
コンパイルするまでわからんというのも気持ち悪く無いか?
コンパイラじゃないよねぇ (スコア:0)
OSに任せれば良ぃじゃん。
#三村ツッコミ風で
正直、どこのコアで何の処理が走っているのか?なんてことまで、
プログラマがわからんとイカンというのも気持ち悪くない?
マルチタスクに分割できるとこは、ガンガン分割して、
実際のスケジューリングはOSにお任せ。
これで良いんじゃね?
生産性とか保守性とかナシで、
ガンガンに実行効率重視でってことなら、
なんでもかんでもプログラマが!
…ってのもアリですけどね。
Re:コンパイラじゃないよねぇ (スコア:0)
そもそもSMTってのはメモリアクセスのレイテンシを隠蔽するから速くなるんであって、関係のある(つまりメモリアクセスの競合がありうる)スレッドを同時に実行すると効率が下がるはず。だからOSとしてできるのは、むしろ無関係なタスクを投入してやることくらいじゃないかなあ。
# 一応私は組み込み系の人ですけど、(密結合の)マルチプロセッサシステムなんて触ったこともないですよ orz...
Re:コンパイラは? (スコア:0)
数値計算サーバのような特殊な分野は別として。
Re:コンパイラは? (スコア:0)
Pentium系だとu-v命令ペアとか uOPにしたときの充填率とか SSExへの変換とか
MIPSだとソフトウェアパイプラインぐらいしか思いつかないけど
手続き型言語で書かれたコードからスレッド並列性を自動抽出してくれる最適化コンパイラって聞いたことないですね
早大の笠原先生のところのマクロタスクスケジューラとかはそういうのできそうな気もしてたんですけどどうなんでしょう
並列処理命令のある言語用のコンパイラ(HPFとか)は
だいたいSPMDのコードを想定
Re:コンパイラは? (スコア:0)
つIntel Compiler
Re:コンパイラは? (スコア:0)
じゃあなんでスレッド化ツール [xlsoft.com]なんてものが別にあるの?
8コア、16コアと続いたら (スコア:1, おもしろおかしい)
へ? (スコア:0)
日本語で (スコア:0)
対応ソフト (スコア:0)
ハードウェアもそうだけど、ソフトウエアもどう進化していくのでしょうかね。
ハード側はマルチコア、メニーコアで進化していくと言っても、
実際には対応するOSやアプリケーションがなければ、 絵に描いた餅状態でしょう。
サーバーに必要な機能なんかは分散処理しやすいのかもしれませんが、
メニーコアになって実際にパフォーマンスは上がるの?
Re:対応ソフト (スコア:1)
個々の仮想環境にCPU割り当てればOK。その上で動くOSはマルチコア対応でなくても大丈夫。
しないさせない!スルー力
Re:対応ソフト (スコア:0)
クアッドコアのCPUがあって、どちらもコアは同じものだったとして、
そこに2つのスレッドを走らせたら、やっぱりどちらも処理性能は変わらないような気がするのですよ。
(そのとき、クアッドコアの2つのコアは遊んでいるのではないかと)
でも、将来的にはどんな(例えば過去の遺産的な)アプリでも、コア数に応じてパフォーマンスが上がってくれないかなぁ、と夢想するわけですよ。
そう言った意味で現状でのOSやアプリはそこまで行っていないよね・・・。
でもサーバー向けの専用アプリとかだったらコア数に応じて実装を変えたりとかしてるのかな・・・。
Re:対応ソフト (スコア:1)
> クアッドコアのCPUがあって、どちらもコアは同じものだったとして、
> そこに2つのスレッドを走らせたら、やっぱりどちらも処理性能は変わらないような気がするのですよ。
> (そのとき、クアッドコアの2つのコアは遊んでいるのではないかと)
確かにスレッドが2つしか存在しないならそうなりますが、実際問題としてサーバではプロセスやスレッドが何十、何百と動いてるのが普通だと思います。
例えばApacheで同時に10コネクションの接続があれば、10個のプロセス又はスレッドが実行されるわけで。
デスクトップでもタスクマネージャで見れば沢山プロセスが起動してますね。それだけでも(多少は)効果があるんじゃないかと。サーバほどではないでしょうが。
しないさせない!スルー力
Re:対応ソフト (スコア:0)
そもそも古いアプリだと、アルゴリズムも練れてなかったり少ないメモリで動かすために速度を犠牲にしてたりするんで、無理に高速に動かしてもあまり意味無かったりしますけど。
Re:対応ソフト (スコア:0)