ものすごく久しぶりにKスタ（http://www.kds.kddi.com/）へ行ってau夏モデルのホットモックを触ってまいりました。久しぶりだった原因は、まあ新機種発表会が毎回お葬式状態だったから他ならないのですが、ハイスペック大好き人間として初のSnapdragon搭載機が出たからには行くしかないでしょってことで、久しぶりに個人的な感想をお届けします。

　恒例の留意事項ですけれども、以下はKスタ展示機（評価機）をいじった結果の個人的な感想であって、反応速度や体感は個人個人によって異なります。ご購入の前には出来る限りホットモックを触られることをオススメします。

　さてさて期待のKCP3.0ことSnapdragon搭載機ですが、当たり前ですがソフトウェア的な違いはKCP+と皆無で、まさに謳い文句（？）通り、”Snapdragonプラットフォームへそのまま移植したKCP+”です。なので基本的に出来ることに違いはありませんが、やはりなんと言ってもとにかく「サクサク」動いていて、今までのKCP+とははっきり言って雲泥の差という状態でした。au MediaTuner を使用したときや、あらゆる切り替え時に感じていたあのもっさり感は全く無く、KCP登場当時に発売されたW21Sを彷彿とさせるサクサク感は、auユーザーが待ち望んでいたことなんじゃないかなと。
　KCP3.0を搭載した機種としてはBRAVIA Phone S004とREGZA Phone T004の二機種ですが、触ってみた限りメニュー構成は一緒のように感じました。特に個人的によく使用するメモ帳（「クリア／メモ」ボタン→「メモ帳」）が相変わらず一番下なのはちょっと気になります。他のメーカーでは一番上に来るモノもあるようなので、自由に並び替え出来れば良いんですけどね…
　そのほか、現在使用しているCA001と比較して違うこととして、マルチプレイウインドウは（やっぱり）無くなっていました。確か去年の秋冬くらいから無くなっていったかと思いますが、KCP3.0機でもこれは変わらずということのようです。もちろん今後復活する可能性はありますが、個人的には今まで一回も使ったことがないので無くても良い気がします。（もちろんKCP+機と同様、ブラウザ起動中にバックグラウンドでメールを開いたりとかはできます）

　KCP3.0の二機種で比較すると、見た目ではBRAVIA Phone、操作性ではREGZA Phoneという感じだと思います。BRAVIA Phoneは見た目の統一感というかスッキリ感というか、そういったところに秀でていますが、REGZA Phoneはなんかガッカリ感漂うケータイ（特にサブ液晶周りとカメラモジュール周り）ですし、反対にBRAVIA Phoneのシートキーはものすごく押しにくいけれども、REGZA Phoneのキーは非常に押しやすい、といった感じです。（ただREGZA Phoneで、エンターキーをおしても入力されないことがあったのはバグなのかそういうキーなのか不明でした）
　この二機種から選ぶとすれば、それほど携帯を使用しない自分としてもキーの打ちやすさは外せないので、REGZA Phone T004を選ぶことになると思います。

　長くなりましたので、後はKCP+搭載機をさっくりと。
　KCP+のブラッシュアップもだいぶ頑張ってきているみたいで、現在所有しているKCP+機CA001との比較でも、待ち受けとメインメニュー間の切り替えは早くなっていたような印象です。それでもやっぱり謎の引っかかりは感じてしまうので、そこは割り切る必要があるかもしれません。基本的にはほとんど現在発売済みの端末の焼き直しに防水を足しただけ、といえばそれまでなので、実際の端末価格で差がでるかどうか、というところでしょうか。
　各機種の特徴は公式の製品ラインアップ（http://au.kddi.com/seihin/）を見ていただきたいのですが、現物を見て気になった点として、展示機のCA005はすでに液晶にキー痕がついていたことで、これはちょっといただけないなあと…

　まとめとして、Snapdragon搭載機は、自分のような今まで端末がもっさりもっさり言っていた人には朗報じゃないかと思います。機能自体はほとんどKCP+と3.0で同じなので、あとは処理性能に目を向けるか、それとも好きなメーカー／デザイン／機能のモノを選ぶ、あとは価格次第、ということで問題ないと思います。

　サブマシン（ゲーム、エンコード用途機）向けにCore i7-980Xを購入しました。

　　

　画像は左から巨大なパッケージ、Windows7のエクスペリエンスインデックス、3DMark06の結果となっております。

　今回Core i7-980Xを購入するのに合わせて、電源ユニットも80PLUS認定品に変更したりしましたので、せっかくなので消費電力とCPU温度も比較してみました。
　なお消費電力の測定には、APC社のUPS RS1200（http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=BR1200LCD%2DJP&total_watts=200）を、CPU温度測定にはHWMonitor（http://www.cpuid.com/hwmonitor.php）を使用しています。

＜変更点＞
　CPU：Core i7-920 → Core i7-980X
　　※CPUクーラーはANDY SAMURAI MASTER＋MAGMA FAN 12cmで変わっていませんが、グリスをGC-EXTREMEに変えました。920で使用していたグリスは失念してしまいました…（すいません）
　電源：Scythe 鎌力4 Plug-in 650W 剛力短 Plug-in 500W → Seasonic SS-750KM 750W
　　2010.05.13追記：鎌力4は80PLUS電源でしたので再確認したところ、鎌力4ではなく剛力短でした。お詫びし訂正させていただきます。申し訳ありません。

＜ベンチマーク結果＞
　SuperPI 1677万桁：6分25秒 → 5分02秒
　3DMark06：14872（SM2.0：6232／HDR：6306／CPU：4612） → 16,675（SM2.0：6755／HDR：6413／CPU：7203）

＜消費電力／温度比較＞ （室温 20度の環境下での測定）
　アイドル時（Windows 7起動後 5分経過時点）：195W 39度→ 170W 37度
　SuperPI実行時の最大：226W 54度 → 203W 47度
　3DMark実行時の最大：314W 67度 → 282W 57度

　んで、せっかくなのでさらにVGAをGeForce 9800GTX+ 55nmからRADEON 5850に変更してみたところ、

3DMark06：21,226（SM2.0：8188／HDR：9365／CPU：7167）
消費電力：279W　※さらにアイドル時は150W

という大満足な結果となりました。
　もう一つの主たる使用用途であるエンコードですが、MPEG-2 TS 1440x1080iソースからDivX 640x360への変換でちょうど1時間かかっていたものが37分に、DivX 1920x1080への変換で3時間20分かかっていたものが51分（！）に短縮され、当たり前ではありますが、i7-920とは雲泥の差となりました。（値段も、920購入当時と比較しても3倍しましたしね…）

　もちろん自己満足の世界なので、だからどうした、とか、上には上が、といわれればそれまでなのですけれども、何かの参考になればと思います。

　ついにイーモバイルのS11HTからApple（あえてSBMと言わない＾＾；）のiPhone 3GSにMNPしてきました。（実は勢い余ってMacBook Proを買いそうになったのは秘密）

　とりあえず連絡先を何とかしてスマートに移行しないと…

　以前Core i7購入時のエントリでも書きましたが、長らくCore i7（X58チップセット）＋GeForce＋HDRECSの組み合わせでOS起動時にハングする問題ですが、NVIDIAが提供している最新版ドライバで解消されたようです。
　WHQL Driver 182.50、並びにベータ版 185.81で正常動作を確認しています。

　せっかくなのでやってみました（馬鹿）
※真面目にマネをしない方が良いと思います…
＜構成＞
　PhotoFast G-Monster-V2 256GB×4
　HighPoint RocketRAID 3510

　前回のエントリでPhotoFast G-Monster-V2をRAID0で投入してみましたが、いよいよ（個人的には）本編の、SSDでエンコード速度が向上するのかを試してみます。

　より実際に使用する例に近く、ということで、今回は24分程度のアニメ動画を用意し、DivXへのエンコードを試してみることにしました。何故今までと同じ（実写動画をH.264エンコード）ではないかというと、実写ソースならH.264にしたほうがよく見える→わざわざDivXを使用しなくとも、H.264を使用する→H.264ならどう頑張ってもFIRECODER-bluには勝てない、という理由からです（笑）
　さらに今回は、せっかくIntel Core i7を使用しているのだから、ということで、Intel Turbo Boostを有効にして計測してみました。

■ 元データ情報
映像コーデック：Canopus HQ Codec（オンライン－標準）
音声コーデック：非圧縮WAVE 48kHz
ソースの解像度：1920x1080（29.97i）
ファイルサイズ：11,146,128,668バイト（10.3GB）
クリップの長さ：23分34秒

■ エンコード環境
M/B : MSI ECLIPSE SLI
CPU : Intel Core i7-920
Memory : DDR3-1066 1GB×3
OS : Windows Vista Service Pack 2β
HDD : BUFFALO HD-QS2.0TSU2/R5（RAID5 / eSATAへ接続）
SSD : PhotoFast G-Monster-V2 ×2（RAID0 / ICH10Rへ接続）
エンコーダ : TMPGEnc 4.6.3.268 ＋ DivX 6.8.5製品版
TMPGEncのフィルタ : デフォルト設定
DivX Codecの設定 :
　レートコントロール＞「1パス-品質依存」
　コーデックパフォーマンス＞「最も優れた品質」＋「SSE4を使用可能」＋「エンハンスドマルチスレッド」
※出力解像度＆音声フォーマットとDivXのフィクスドクォンタイザは後述します。
※HDDでもSSDでも、入力元ファイル／出力先ファイルは同じドライブを使用しています。つまりHDDならHDDから読んでHDDへ書き、SSDならSSDから読んでSSDへ書き込んでいます。


▼ ケース１：出力解像度を640x360 29.97i（SD）、音声をmp3 192kbps Joint Stereo、クォンタイザをQ4にしたケース

　まずは単純にHDソースをSDソースに変換する例です。画像は左列がHDD（上段がTurbo Boostオン、下段がオフ）での結果、右列がSSD（こちらは両方ともTurbo Boostオンで、上段がストライプサイズ128K、下段が4K）での結果となっています。
　結果を並べると、31分14秒：27分46秒：26分00秒：25分46秒ですので、HDD/Turbo Boost無しを基準とするとそれぞれ 0分 0秒：－3分28秒：－5分14秒：－5分28秒、クリップの長さと比較した割合はそれぞれ 132.5％：117.8％：110.3％：109.3％ となり、予想通りの結果となりました。とはいえ（人によっては）たった1分46秒の差が6.5万（RAID0なら13万）、と考えると微妙とも言えますが、ここをプラス思考として考えるのなら、13話分まとめてバッチエンコードすると約1話分時間が空く、ということになります（＾＾；

▼ ケース２：出力解像度を1920x1080 29.97i（HD）、音声をmp3 192kbps Joint Stereo、クォンタイザをQ4にしたケース

　読み書きの量が多くなれば、当然差も広がってくるのではないかと考え、HDソースをHDソース（のDivX動画）に変換する例で比較してみます。画像の並びは先と同様、左列がHDD（上段がTurbo Boostオン、下段がオフ）での結果、右列がSSD（こちらは両方ともTurbo Boostオンで、上段がストライプサイズ128K、下段が4K）での結果となっています。
　順番に結果を並べますと、42分42秒：40分17秒：36分24秒：36分09秒、差はそれぞれ 0分 0秒：2分25秒：6分18秒：6分33秒、クリップ比ではそれぞれ 181.2％：170.9％：154.5％：153.4％となります。HDへの出力では4分程度の差が発生しているあたり、SSDの強さを遺憾なく発揮したというところではないでしょうか。
　逆にストライプサイズは、ベンチマークの数値ほど影響を与えていない結果になっているのも興味深いと思います。この辺りはCrystalDiskMarkやHD Tuneの測定ロジックによるところだと思いますし、アクセス方法はアプリケーション毎に違いますから、難しいところではないかと思います。

▼ ケース３：出力解像度を640x360 59.94p（SD）、音声をmp3 256kbps Stereo、クォンタイザをQ2にしたケース

　いわゆるインタレソースの2倍fps化というヤツです。最近はインタレ保持したままでも、再生側でデインターレース処理を行うことで綺麗に表示することが出来るようになっていますが、色々と考えるのが面倒くさいので（笑）ウチではこの設定を主に使用しています。なおこれはSSDのみで、ストライプサイズでの比較を行っています。
　結果は26分03秒 対 27分02秒 で、これはなんと逆にストライプサイズの大きい方が1分程度早い、という結果になりました。
　で、さらに同じ設定を Core2Quad Q6600＋HDD で実行してみたものはこちら。
　ソースの3倍弱となる、1時間04分03秒で処理が完了していました。Core i7（TurboBoost有り）＋SSD（ストライプサイズ4K）であれば、ほとんど同じ時間で 1920x1080 59.94p、音声 256kbps Stereo、クォンタイザQ2 の処理が完了しているあたり、技術の進歩は凄いなあ、と痛感しました。
---
2009/01/05 6:47追記：
　Core2Quad Q6600のエンコード時間ですが、映像クロップフィルタと音声ノーマライズフィルタが追加されており、全く同じ設定ではありませんでした…申し訳ありません。
---

▼ SSDをICH10RのRAID0でなく単体で使用した場合はどうか

　左からケース１、ケース２、ケース３、オマケの1920x1080 59.94p Q2 の順です。
　SD画質のQ4というかなり限定された構成（ケース１）では、23分19秒（98.9％）とやっと100％切りを達成。ICH10RはソフトウェアRAIDなので、この処理にかかるCPU負荷が、SSDのRAID0化で向上した速度よりもエンコードに影響を与えた、という結果になりました。
　それ以外もケース２が36分07秒、ケース３で27分09秒、オマケで1時間03分08秒となり、いずれもICH10RでのRAID0より早いか、またはほぼ同じ時間となっています。つまり容量以外ではソフトウェアRAIDにする意味は何もない、ということになります。
　エンコードでプチフリーズ判定ができるのかどうかはわかりませんが、少なくとも読み書きを激しく行っているはずのエンコード処理において、目に見えて処理が停止するようなことは全くありませんでした。（もっともプチフリーズは、複数のI/Oが並列に発生しないと起こらないので、エンコード処理くらいでは該当しないかもしれません）


■ まとめ

- H.264へのエンコードは素直にハードウェアエンコーダを使用したほうがよい。（これは前から変わらず）
- ソフトウェアエンコードでIntelプラットフォームなら、Core i7＋Turbo Boostで使用するのをオススメ。（※AMDプラットフォームは、省電力のe系統しか触っていないのでよく分かりません^^;）
- PhotoFast G-Monster-V2使用では、HDDよりそれなりに早くなる。ただし価格に見合っているかどうかは各個人次第。
- PhotoFast G-Monster-V2＋ICH10RでのRAID0には、”エンコード速度”の観点に限った話ではうまみがほとんど無い。
- ただしまともなハードウェアRAIDコントローラでのRAID0では、結果が変わってくる可能性がある。

　以上、多分全く参考にならないレビューをお届けしました＾＾；

　最初タイトルに「～を試す」と付けたら、某Watchみたいな見出しになったので却下。
　というわけでPhotoFastの赤SSDことG-Monster-V2を2台購入してみましたので、早速色々テストをしてみました。

　マザーはMSIのECLIPSE SLIで、RAIDも試したいという魂胆からDriveBooster（JMicron 322）のSATAコネクタに接続、ベンチマークを取ってみました。
　…あれ？Readで140MB/s？
　じゃあRAID0にしてみたらいいのか？と…
　まったく変わらない結果にがくり。
　これはオンボードRAIDコントローラではやっぱりしょんぼりな結果にしかならんのか、と思いつつ、上田新聞blog版を見てみると、ICH10Rで200MB/s越えの結果が。
　で、早速現在ICH10Rに接続されているHDDをJMicron 322側（※このコントローラ側からでもブートできる上に、仮にこのコントローラの転送速度が最大140MB/s程度だったとしても、HDDなので十分）につなぎ替え、逆にICH10RへSSDを接続してみると…
　ほぼ期待通りの値、READで209MB/s、WRITEで163MB/sとなりました。
　では気を取り直してRAID0（ライトバックキャッシュOFF）にしてみます。
　Sequential READは268MB/sになりましたが、Sequential WRITEは133MB/sと低下、逆にRandom READ/WRITE 512KBはそれぞれ237MB/s、85MB/sと上昇。またHDTuneのBurst Rateは低下、という妙な結果となってしまいました。
　これでも十分早いし…と思ってはいましたが、やはり納得できなかったためGoogle先生に聞いてみたところ、ストライプサイズを小さくすると良い（ICH10Rのデフォルトは128K）らしいとの情報が。

　早速ストライプサイズを4Kにして論理ボリュームを作成してテストをしてみます。
　IntelのSSDでRAID0を組んだケースには遠く及びませんが、容量は2台構成のRAID0で3倍程度で、価格差は現時点で約＋2万ですから十分とも言えます。
　逆に言うと、単体で512GBになれば、容量以外ではほとんどRAIDにする意味が無いかもしれない、という点ではなかなか面白いかもしれません。（もっとも、まともなハードウェアRAIDカードを付ければ結果は違うのかもしれませんが、残念なことにそこまで投資できませんでした。そもそもICH10RであってもIntel SSD RAID0で470MB/sくらい出せるので、キャッシュ以上の速度向上はあまり見込めないのではないか、と思ったためです）

　HDDと比べると圧倒的な速度となりましたので、次回はこれがエンコード速度に影響を与えるのか、チェックしてみようかと思います。

---
2009/01/04 15:13追記
　Google先生に聞いてみたところ、inDEXさんがAreca ARC-1680ix-12というハードウェアRAIDカード（10万以上する高級RAIDカード）で試される予定であるというエントリーを見つけました。ちょっと期待。