アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
アクセラレートされていない (スコア:3, すばらしい洞察)
Cellの特徴であるストリームプロセッサは依然として生かされていません。
じゃぁそれなりの速度のPowerPCと専用のデコーダを積めばいい(両方足してもCellより安い)わけで
Cellにしたメリットって?
・ ソフトのアップデートだけでCODECの追加とか全然違う機能が付けられる。
・ SPEの言語/OSサポートはFPGAよりは良い
・ 在庫一掃セール
Re:アクセラレートされていない (スコア:0)
ここでしょうね。
それよりもなぜわざわざRubyを使ったのかがよくわからなかった。
GUI構築なら、Flashなどの方がやりやすいんじゃないか?
Linuxに東芝の中の人がContribしてる件について(Re:アクセラレートされていない (スコア:2, 参考になる)
Flashはライセンス関係がキツキツ過ぎる上に中間コードにしてしまいますからデバッグも厄介…と言うのは他の方もすでに書かれていますが、
GNU/Linuxベースのファームウェア乗せている家電などの組み込み事例も普通になりかけてる(てか、そもそもそこまで高度にしないで行く場合が多いですが)状況で、実際LinuxカーネルのPPC版のCell対応の為に東芝とIBM(とSONY..どうなるのやら?)の中の人が沢山コード寄せてる状況 [kernel.org]な訳で
…今回のキモはUIとかリアルタイム性の低い制御部分をRuby(+多分FBDevかX11ベースのGUI)で書けるように出来ましたよーん。って事だと思いますよ。
OS部分とRubyインタプリタがしっかり安定すれば(こちらはこちらで匠の技が必要になるけど)、UI部分書いていた人たちはコンパイラとデバッガから解放されるはず。従って、UI廻りの生産性も上がるし、複数のデザインの提供や部品の使いまわしも容易になるはず。と言う目論見でしょう。(多分、RoR前提で開発考えてる?)
両方ともGPLだけどGNU/Linux(BSD?)ベースならばライセンス的にまずいのはデバイス固有のドライバのソースコードとブートローダ部分を公開する義務が基本的には発生する辺りで、
ユーザスペース側からConnectorあたり通して(さもなければバスとかI/Oとか直接叩く部分だけ抽象化してユーザ側からた叩けるパッチ出して)、制御本体やプロトコル的な部分込みでユーザスペース側のドライバを組めば、DRMやらNDAやらで機密の塊の部分を独立した暗号化バイナリにしてしまう事も最低ではLinuxでも出来てしまう訳で
SPUの演算は別腹ですよ…と言うか予め用意しておいたコードをSPUに突っ込んでストリームをつないでSPUに処理させる程度ならしかるべきランタイム拡張さえ用意できればRubyからでもSPUいじれるような(^^;
その辺はどこまで文字列インタプリタでやるのがリソース的に許されるか。ってあたりになるんじゃないですか。
そういう意味で、生産性とインフラ全面的に変えた場合の相互融通性だけ見れば本当にCだアセンブラだ使うのはハードウェアなどに密着してるあたりやインフラ部分などの最低限にして、
アプリケーション層自体はJavaやVBのように中間コードすら使わないで、RubyやPython、PHPのように書いたまんま直ぐに動くインタプリタでやっちゃいましょう。と言うのは合理的ではありますよ。
リソースどうしょうもなく喰うの覚悟すれば。そして、半導体量産技術の急速な進歩で、それだけ「覚悟」するのにそんなにコストかけないで済むようにもなってきている
そう言う意味では、Cellはかなり「高級組み込み向き」なMPUに当たるんじゃないですか?
一からアプリ書く場合にはx86系で組むよりも楽で消費者側のコストもかからないようにできる気がしますよ。
何を処理させるかによるけど、大概のプログラムの場合はX86でやるよりはPPCあたりで書いた方がリソース浪費に関しての効率いいですから。(少し前まではこの手のものってARMやMIPSベースのMPUが家電向けの組み込みMPUではトレンドだった気がするんですが…PPC使う場合って、元から安価な組み込みに入れられるように色々細工できる余地を作ってある405系コアのチップはともかく、それ以前はそれなりに値の張る相手に使っていた気が ^^;)