アカウント名:
パスワード:
PS3向けは1石でSPEが7つ使えないと困りますが、大量に搭載するサーバなら平均4~6個なんて計算でも、価格が相応なら問題ないわけで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
CELLの供給先 (スコア:3, すばらしい洞察)
SPEが7個動くCELLチップ→PS3へ
SPEが8個動くCELLチップ→サーバーへ
今後上記のような供給になるんでしょうか。
CELLの歩留まり計算 [blogs.com]
Re:CELLの供給先 (スコア:1, 参考になる)
あとPS3用のCELLは大分TSセミコンダクタで生産なので
IBMからの供給ではありません
Re:CELLの供給先 (スコア:0)
Re:CELLの供給先 (スコア:0)
プロセッサーって演算ユニット以外も損傷してる可能性があるわけで
その場合不良品になると思いますが
SPEに欠陥部分が集中する理由はあるのでしょうかね?
10個入れて8個動かす方が確実だと思うんだが…
Re:CELLの供給先 (スコア:1)
増やすとレイテンシに問題が出るから8個なのでは?
これ以上増やそうとしたらPPEx2構成にしないと
キレイに回らないのかな、とか。
Re:CELLの供給先 (スコア:0)
Re:CELLの供給先 (スコア:0)
「SPEに欠陥部分が集中する」のではなく同じものが複数あるからそこに欠陥があってもなんとかなるだけのことで、実際にはほかの原因でうごかないものは当然でているかと。
仮にSPE1つの歩留まりが90%だとしてSPEが8つ全部動く確率と7つだけ動く確率はかなり変わるはずです……計算間違いが怖いので数字は出しませんが:-)
Re:CELLの供給先 (スコア:0)
Re:CELLの供給先 (スコア:4, 参考になる)
8つとも動く確率は 0.9^8 で約43%
7つ「だけ」動く確率はSPEが8個あってそれぞれの歩留まりが90%とすると
□■■■■■■■ 0.1x0.9x0.9x0.9x0.9x0.9x0.9x0.9
■□■■■■■■ 0.9x0.1x0.9x0.9x0.9x0.9x0.9x0.9
略
■■■■■■■□ 0.9x0.9x0.9x0.9x0.9x0.9x0.9x0.1
の8通りがあって、合わせて約38%
ただし普通求められるのは7つ「だけ」ではなく7つ「以上」動くプロセッサですから、
そうなると歩留まりはこれらの合計、約81% にまで跳ね上がるのです。
てよくみたらリンク先に全部書いてあるじゃん・・・orz
先人の知恵をちゃんと読めよ、愚民ども(含オレ)
Re:CELLの供給先 (スコア:0)
Re:CELLの供給先 (スコア:4, おもしろおかしい)
Re:CELLの供給先 (スコア:0)
Re:CELLの供給先 (スコア:0)
単純に占める面積の割合が大きいから、ってだけでは?
同じように面積が大きいキャッシュも欠陥部分を予備と入れ替えたりします。
SPEの場合はその粒度が大きいので目立つのかと。
10個入れられてたら、10個動く石がサーバーに、8個動く石がPS3に、ってなるだけだと思います。値段は上がりますが。個数が変わるだけでメソッドはかわらんでしょう。「8個」という数字に意味がある訳ではないので。
Re:CELLの供給先 (スコア:1)
PS3向けは1石でSPEが7つ使えないと困りますが、大量に搭載するサーバなら平均4~6個なんて計算でも、価格が相応なら問題ないわけで。
どれだけ (スコア:2, 興味深い)
それだけの労力に見合う性能が出るかがキモになってくるのだと思います。
一部のライブラリをPS3側から反映するのかなぁ?
もちろんFedora自体も性能が出るようにチューンされているのでしょうね。
OSがボトルネックになるなら意味無いし。
Re:どれだけ (スコア:2, 興味深い)
「アプリケーションの書き換え」と言ってもミドルウェアレベルの書き換えよりはアプリケーション自体をSPEに対応させる書き換えでないと意味が無いでしょうから、マルチメディアアプリ(MPlayer [mplayerhq.hu]やAvidemux [avidemux.org]、FFMpeg [mplayerhq.hu]など)で今までアセンブラで書かれていたりしたコア演算部分をCELL用に書き起こすか、後述のブートローダOS対応のミドルウェアを叩く格好に書き直すって感じでしょうね(SDK入手できればどーすればいいのかわかるでしょうけど、まだ入手していないのでわからん)…後は、各種のCodecやX.Orgの一部コードやMesaあたりを対応させれば十分なんじゃないかな…
他の通常のアプリケーションはgccやglibcが対応するを待つのでもいいのでは無いかと…
>もちろんFedora自体も性能が出るようにチューンされているのでしょうね。
>OSがボトルネックになるなら意味無いし。
これは小耳にはさんだ程度の噂話なんですが、このマシン(やPS3?)はタスク管理もやってくれるVM上で複数のOSカーネルが並列に動くように作られているようです。
具体的には、BIOSやOpenFirmwareと呼ばれているような単なるブートローダだったレイアの部分がそこそこ高度なRTOSと言っていい物になっているはずです(これは噂の上にこのWSで使われているかどうかは正直不明なんであまり詳しくはかけない…)
このレイアで、通常のPPC/PPC64用のLinuxカーネルでもパフォーマンスが出るようにかなり調整されてるんではないかと。
# しかし、何故、Fedora?せめて、RHELとか言ってほしかったなぁ…(^_^;
Re:どれだけ (スコア:2, 興味深い)
この記事がCellプログラミングの一例として、またGPUの挙動を知るという点に
関しても、面白く読むことができました。
ひとつのSPE内でスレッドを切替えるという手法についてものっています。
SUSEでしょ (スコア:1)
やっぱ、SUSE Linuxでしょう。
なんか最近、IとNは、ちょっと仲良い [nikkeibp.co.jp]みたいだもの。
って、
我ながら説得力無いなぁ…。根拠弱いよなぁ…orz
Re:SUSEでしょ (スコア:0)
Re:どれだけ (スコア:0)
「自らの環境で構築」が基本なので、新アーキテクチャ対応にはGentooが強いですね。だってバイナリパッケージが用意されるのを待つ必要がないですから。自前でごりごり。
GentooもCellへの取り組み [gentoo.org]が着々と進行中です。
Re:どれだけ (スコア:1, すばらしい洞察)
Re:どれだけ (スコア:0)
http://www-cr.scphys.kyoto-u.ac.jp/member/nakamori/ppt/tenmon_2006spri... [kyoto-u.ac.jp]
http://www.ne.jp/asahi/comp/tarusan/main148.htm [www.ne.jp]
OS (スコア:1)
# 今さらデータシートを読んで気がつきました m(..)m
http://www.bsc.es/projects/deepcomputing/linuxoncell/ [www.bsc.es]で開発しているFC5ベースの専用GNU/Linux OSか、これをライセンス違反しない形で他のGNU/Linux OSに移植した物(多分、同じページにあるSDKが必要になると思う)でないと、このWSでは動かないですね。
既に、#1019843 [srad.jp]で書いてしまいましたが、このWSはRTOSとも言えるVM上で複数のOSカーネルが動く構造になっているようですので、普通のハードウェアに依存したOSだと動かないのでは無いかな…(いちおう、噂ですが)
むぅ。これは... (スコア:1)
一台のサーバ上でPS1〜2のゲームを実行させるのに、
最高のプラットフォームということですね。
#ラブホテル街のど真ん中に住んでいるので、ふと、そんなことを。
-- LightSpeed-J
価格 (スコア:0)
Re:価格 (スコア:0)
Re:価格 (スコア:0)
Re:価格 (スコア:0)
Re:価格 (スコア:0)
Re:SGI (スコア:1)
あとは、IRIX Reactが、SUSE経由で移植されるのを待つばかりですね。
sf.jp で有志を募りますか。
Re:名無しさん (スコア:1)
それは地球シミュレータ1ノードと比べた場合ですか?
この記事 [nikkeibp.co.jp]によると「倍精度も70GFLOPS以上になる。」
ってあるから地球シミュレータ1ノード64Gflopsでつじつまが合いますね。
ところでそのブレード何に使ってるんですか?
#所詮縁遠い人です。
Re:名無しさん (スコア:1)
# ネタにマジレスカコワルイ>俺
まぐろたべたい
Re:名無しさん (スコア:0)
Re:名無しさん (スコア:0)