PS3に必要なソフト

日記

PS3の値段が発表されました。

http://www.watch.impress.co.jp/game/docs/20060509/scej.htm

安いほうで62790円、高い方だと75000円くらいですか？

高いよね。普通買いませんよ、こんなの。私にとっては、どう考えてもWiiのゲームの方が面白そうだし。

という感想を書いて終わりだと、面白くも何ともないので、どうやったらPS3をてこ入れできるか考えてみましょう。

プリンタドライバ

PS2はHDDが無かったから、プリンタドライバの問題を解決するのが難しかったと思うんですが、PS3ならHDD標準搭載でHDDにOSまで入っているということで、あとはEPSON,Cannon,HPなんかにPS3用(Linux用)プリンタドライバを開発してもらって、WebにあげてもらうかPS3のOSに標準添付しちゃえば良いわけです。プリンタドライバがあると、夢がひろがりんぐ！っすよ。

メディアサーバ

写真とか音楽ファイルをHDDにため込んで整理したり、PSPにエクスポートしたりするソフト。PSPを使うのにPCが不要になる。まあ、これくらいはもともと付属してくるでしょうけど。
でも、プリンタ機能があるのと無いのでは大違いですよ。やはり、おじいちゃんやおばあちゃんに見せるのにはパソコンのデータより紙の印刷が便利ですし、飾ったりするのにも紙印刷は必要ですからね。

年賀状印刷ソフト

PS2時代から思っていたんですが、筆まめとか筆ぐるめとか年賀状印刷ソフトをPS3に出したら良いと思うんですよね。プリンタドライバの問題が解決すれば、これも楽勝でしょう。


西川善司さん（因みにOh!X時代から氏の記事はよんでおります)が

http://www.watch.impress.co.jp/game/docs/20060511/ps3.htm

で、『PS3に必要なもの〜それは「Office for PS3」』っておっしゃってますけど、私はそうは思わないです。

昨今の、Winny騒ぎのおかげで私有PCに業務データを入れるのは、非常に厳しく制限される流れになってますから、よほど意識の低い（か、お金のない）中小企業にお勤めか、あるいはフリーランスの方でなければ、自宅の私有パソコンでOfficeを使う必要がある場面っていうのは、相当減って来ていると思います。実際、私は先日新調したPCにMS Office入れるのやめましたが、それでも、全く問題ないです。必要な人は会社からノートPCが支給されるでしょうし、そちらに入っているMS Officeで仕事します。

自宅で必要なのは、ウェブブラウザ(pdfブラウザ含む)、メールクライアント、写真や音楽ファイルの整理と印刷ソフトと保管用ストレージ、そして年賀状印刷じゃないでしょうかね（米国だと税務申告ソフト)あ、あとソリティアも（＾＾；
もしPS3で、これらのことがすべてエレガントに済ませられるなら、PCが不要になるひと多いと思います。で、Windows PCの予算をPS3にまわしていただくというわけです。Windows PCと比べれば、PS3もそれほど高い訳ではないですし、PCのように 2,3年で買い換え時期がやってきたりしないので、そういう点をアピールすれば勝算があると思うんです。

Webで公開されているMS Office製の資料（最近はpdfになってるのでほとんど見かけませんが)を見るためや、ちょっとした表計算程度であればOpenOffice.orgで十分です。

PS3には、標準かどうかわかりませんがLinuxが載るそうですし、（実際Linuxのソースツリーを覗くと、arch/powerpc/cellというディレクトリがあって、いろいろと楽しませていただいております）、あとはCREOとかに移植してもらうだけなんですけど、だめですかね？

いっそ、標準添付とかにしちゃうとインパクトあって良いかも。宛名印刷機能とテンプレートがしっかりしていれば良いので、それ以上凝った機能はいらないから内作してもたいしたコストアップにならないと思うけどな〜。

PSX機能

地上波デジタルチューナーを含むチューナーを乗っけて、HDDレコーダ化っていうのも良いですね。標準搭載なら、８万円も納得の価格だと思います。

PSPと組み合わせてPIMに

以前から言われていることだと思いますが、PSPまたは携帯と連携できるPIM機能をつけて欲しいですね。ソニーの携帯とだけ連携できるというのだと、私は困るのですが、それもよいかもしれません。

まとめ

  1. PS3は高いので性能以外の付加価値をもたせよう！
  2. そのためにはプリンタドライバが必須
  3. 写真や年賀状印刷ソフトがあると良い
  4. 地デジチューナーとレコーダ機能も欲しいなぁ
  5. PIMもくだされ

要は、_自宅_PCの使われ方を良く考えて、それをリプレースできるようにするということですね。

更に余談：動的トレース機能について

上記、http://d.hatena.ne.jp/hyoshiok/20060430#p1に、fjの教祖様が、http://d.hatena.ne.jp/hyoshiok/20060430#c1146410003というコメントをつけてますが、JavaならAspectJとかいかがでしょうか？また、SoralisならDtrace、Linuxならsystemtapもあります。systemtapについては、feedbackいただけるとありがたいですm(_ _)m

余談：HyperThreading環境で性能が低下する件について

件のエントリでは、puase命令を追加しても性能は変わらないが、Hyper Threadingを無効にすると、性能が向上するという結論が示されていました。これは、MySQLのCPUスケーラビリティの無さを示している可能性が高いと予想しています。

ハード構成は16CPUだそうですが、仮に2GHzのマシンだったと仮定した場合、HyperThreadingを有効にすると仮想的に1GHz,32CPUのマシンに見えます。TyperThreadingの場合、CPUストールの際にsiblingが実行されるはずなので、実際にはもうちょっと性能が良いとして、1.2GHz,32CPUのマシンだったとしても、2GHz,16CPUのマシンと勝負して勝てるのは、よほどSMP性能に気を使ったOS/アプリを利用した場合だけのように思います。どちらかというと、MySQLは健闘している方ではないかと。

CPUスケーラビリティ向上の難しさの実例：MySQLの実装に関して

アプリケーションの性能向上を目指した実装の例として、MySQLについて取り上げます。MySQLのソースコードを丹念に読んだわけではありませんので、誤解がありましたら、ご指摘ください。

先月の話ですが、id:hyoshiokさんのMySQLの性能に関するエントリhttp://d.hatena.ne.jp/hyoshiok/20060301#p1で、コメントさせていただきました。

MySQLのmutexは、空回りをして待ちながらmutexの取得に何回かトライし、だめなら一旦あきらめてyeildする実装になっていました。しかし、この実装ではCPUスケーラビリティが低いと思います。予想されるlockの保持時間に合わせて、lockの保持時間がきわめて短い事が確実なlock→spinlock、比較的長時間保持されるlock→トライしてだめならすぐ寝るmutexと使い分けるような実装にする必要があります。また、可能であればthreadの優先度を制御して、lockを保持しているthreadの優先度を上げるべきでしょう。

マルチコア時代のスケーラビリティ

Open Source

主に発熱の問題から、CPUの進化はコアの高性能化の方向性をぐっと減らし、マルチコア化によって、ムーアの法則に則って増え続けるトランジスタを消費する方向に進むことになりました。id:hyoshiokさんが、http://d.hatena.ne.jp/hyoshiok/20060430#p1で指摘されている通り、従来は、アプリケーションを開発する場合、プロセッサ性能やメモリ搭載量は、将来増加することを織り込んで、設計することが正しい戦略であったわけです。

一般にCPUやメモリ、HDDなど、ハードウェアリソースの追加に比例して、性能が向上することをスケーラビリティと呼びます。ソフトウェア開発者にとって、スケーラビリティがあるソフトウェアを設計/実装することが求められてきましたし、これからも求められていくでしょう。実際、高いお金を払って、CPUを２個から４個に増やしたのに、性能は２個のときと変わらないとか、逆に悪くなるということがあれば、ユーザは怒るでしょう。CPU2個のマシンと4個搭載できるマシンでは値段は、１桁違ったりしますし。

しかし、スケーラビリティのあるソフトウェアを開発するというのは、じつは大変難しいのです。例えば、ワーキングセットを下回る様なメモリしか搭載されていなければ、論外なのですが、ワーキングセットに対して十分なメモリが搭載されている状態で、メモリを追加して性能が伸びるというのは、非常に限られたアプリケーションだけです。それどころか、OS/アプリの実装によっては、逆に性能が下がる場合すらあります。

これに対し、CPUはいままで非常にありがたい進化を続けてくれたのです。つまり、アプリケーション側は何の工夫もしなくても、CPUの性能向上の恩恵をそのまま受けることができたわけですから。しかし、今後のCPUは、コア単体の性能向上を望むことはほとんどできなくなります。代わりに、コアの数が増えるわけです。ですからこれからの時代、コアの数に対するスケーラビリティのあるソフトウェアを開発することが求められるわけですが、私はこれに関してあまり楽観的ではありません。

いろいろと論文を漁ると、CPUのスケーラビリティに関する物がでてきますが、私が見た範囲でスケーラビリティが一番あるOSでも、16コアくらいで性能向上が頭打ちになっています。それもかなりマルチプロセッサ環境に向いたベンチマークを利用した場合にです。一般的には、4〜8コアくらいが限界だろうと思います。それも、コア数に対する性能の比例係数は、1ということはなく、0.1〜0.6といったところがが良いところではないでしょうか。もちろん、CPUのコア数に関するスケーラビリティは、アプリケーションに非常に強く依存するので、コア数に比例した性能がでるアプリケーションを否定する物ではありませんが、世の中の多くのアプリはそれほどCPUに関するスケーラビリティが無いのではないかと思っています。

さらに問題なのは、CPUスケーラビリティの高いアプリケーションを開発するというのは、非常に難しいのです。性能を向上させるためには、最低でもコア数を超えるThreadを起こして、それをぐりぐり回すようなコーディングをしなければなりませんが、Multi Threadプログラムがバグったときのデバッグは、時に筆舌に尽くしがたい苦難があります。私が無能なだけかもしれませんが。

Linuxでも、CPUスケーラビリティの向上については、2.5時代から様々な取り組みが行われていますが、基本的には(1)lockless設計、(2)lockの細分化、(3)軽量なlockの利用ということに尽きます。(1)については、例えば、slab allocatorは、CPU毎にslab pageのリストを持つことで、allocationのためのlockの削減を行いました。CPU毎にリストを持つことは、メモリの無駄になるわけですが、メモリの無駄を承知でlockless実装にこだわったわけです。(2)については、一番有名なのはBKL(Big Kernel Lock)使用箇所の削減があります。(3)については、例えばSemaphoreをRCU(Read Copy Update)に書き換えることで、性能向上を果たした箇所が多数あります。

OSSはベンダにどのようなメリットがあるか？(ベンダがOSSに取り組む、ちょっと消極的な理由)

Open Source

id:hyoshiokさんが、http://d.hatena.ne.jp/hyoshiok/20060223#p1の中で、

いろいろ考えられるが、わたしの第一次近似は、ユーザがOSSの発展に主体的に関与できる点だと思う。開発コミュニティ、ベンダ、ディストリビュータ、ユーザなどなどOSSを利用するステークホルダは多い。そしてそれぞれの立場の下にOSSに関与しているが、商用ソフトウェアとまったく違うところはユーザがそのソフトウェアに主体的に関与できるかできないかということである。

とおっしゃっています。これは主にユーザ側の立場を代弁されていると思います。
しかし最近では、主にハードウェアベンダ側が積極的にLinuxを中心としたOSS 開発に参加しています。この理由を、私なりに書いてみようと思います。といっても私がよく知っているのはLinuxだけですので、Linuxに限定した話になっちゃいますが。

ハードウェアを売りたい人

現在、Linux開発に非常に積極的に参加しているのは、Red Hat, SuSE(Novell), OSDL, IBM, Intel, HPといったところが中心でしょうか。日本企業では、富士通、NEC、 Sony、Miracle Linux、VA Linux、日立などの名前をLKML上で見かけます。もちろん、IBM等と比較すればたいしたことありませんが。この中で、Distributerが積極的に参加するのはほとんど自明ですよね。Linuxが良くなってくれれば、一度製品を買ってくれたお客さんが、また、続けてお金を払ってくださるわけですから。
では、IBMやIntelを中心としたハードウェアベンダはどうかというと、特にIntelが積極的に参加している理由は明らかで、Intelにとってみればソフトウェアは無料になってくれればありがたいわけです。これは私の推測ではなく、LKMLやXenの開発でも活躍されている、Intel CorporationのNakajimaさんが、私におっしゃったことです。IBMも全ハードウェアラインナップにLinuxをそろえていますが、Linux開発に投資する動機の一つはハードウェアの売り上げにあることは間違いないでしょう。

ハードウェアだけか？

日本のベンダがなぜLinux開発に参加するかと言えば、ハードウェアの売り上げという要素があるにはありますが、それはIntelなどと比べれば、微々たるものでしょう。
では、なぜ参加するか？これを紐解く鍵は日本のベンダのコンピュータ開発の歴史にあります。汎用機全盛の時代、各ベンダはOSレベルでIBM/360と互換性を持ったハードとOSを作ってきました。アプリはIBM/360と同じものが使えるわけです。その後、UNIX系(メインフレーマ用語ではオープン系)システムでは、各社とも独自のUNIX系OSを作ってきました。NEWS(sony)とかEWS-UX(NEC)とかHI-UX(日立)とか。あれ、富士通はSUNのOEMだけでしたっけ？とにかくUNIX系OS百花繚乱です。ところが、このやり方だとアプリが揃わないんですよね。各社ともPOSIXには準拠しているわけですが、ヘッダが微妙に違ったり、機能拡張競争でPOSIXにはないインターフェースをつけまくったりして、同じUNIX系OSといえども、アプリケーションを動かすためには各OSへのポーティングが必要になってしまいました。それでも当初は、フリーのプログラマー雇ってGNUのfree softを移植してもらったり涙ぐましい努力をして自社OSを維持してきたわけです。それも長くは続かなくて、NEWSが消え、DECが消えとやっているうちに、残るはSolaris(SUN), AIX(IBM), HP-UX(HP)になってしまいました。
ところがですね、IBMを筆頭にベンダというのは、ハード＆OS屋さんであると同時にSIerでもあるわけです。作ることをやめても、お客さんにサポート付きでハード＆OSを提供し続けなければならないため、各社ともSolaris,AIX,HP-UXを提供し続けたわけです。大手SIerがサポート付きで顧客にOSを提供するとなると、OSの守秘義務付きソースコード開示契約を結んだり、場合によっては開発元に人を送り込んだりして、自分のお客さんがふんだバグ取りを手伝ったり、場合によっては必要な機能の追加を手伝ったりしてきました。
そうこうしているうちに、Intel processorの性能が良くなってきて、UNIX系OSのエンジンだったRISC processorと同等の性能が出るようになってきました。価格/性能比で言ったら、Intelの方が断然上ということになります。そこで、俄然注目されたのが、Intel Processor上で動作するUNIX系OSのLinuxです。
で、Linuxをお客さんに提供するにあたり、やはり自分のお客さんがふんだバグをつぶしたり、必要な機能を提供したりしなければなりませんので、今までproprietaryなOSに向けてきたエネルギーをLinuxに向け始めたというのが、ベンダがLinuxに取り組む理由じゃないでしょうか？
いくらソースコードが公開されているからといっても、普段開発もしてないのにバグにぶち当たったからといって、いきなりデバッグできるものではないですよ。特に今のLinuxの様な巨大なソースコードになってしまうと、どこに何が書いてあるか、何が原因でおかしな事が起こるか、どうやって解析するか、ちょっとやそっとではわかりません。しかし、不思議なもので一部の機能でも良いから開発に携わっていると、他の部分まで見通しが立つようになってくるんですよね。特にLinuxの場合、開発に携わるとLKMLを結構丁寧に読む必要がありますから、自然に他の部分の情報が入ってくるようになるのが大きいです。