MacBook Pro Retinaをほんの少しだけ見てきた
春先にAirを仕事用に導入したのですが、LionからXcode周りが色々変わったせいでconfigureしてmakeするのがやたらと通りにくく、ネタに事欠いたのでふらっと某量販店に立ち寄って見てきたRetinaなProについて少し。
・ぱっと見は意外とインパクトがない
ドライブのスリットがなかったのですぐに見分けがつきましたが、並ぶ展示機の中、見た目的には目立ちません。フラットな形状なのでAirほど薄さは感じず、液晶も表示領域的には非Retinaと同じなので、まあアイコンや文字がきれいかな、程度のものです。でも改めて横の13インチモデルを見ると、そこそこ薄いはずなのに野暮ったく見えてしまう不思議。
・作業領域優先設定
ハードとOSを両方作っているAppleならではですが、ちゃんとシステム環境設定にスケーリングの項目があり、Retinaディスプレイの表示能力を作業領域に振ることができました。作業領域優先にしたときの精細感はなかなか物欲をそそります。当然ながらOSの部分やSafariでAppleのページを見た限りは非常にきれいにスケールされていましたが、他のアプリでどこまでうまく表示能力を使い切れるのかどうかは気になるところ。まあ製品として出てきた以上、そしておそらくは他のモデルもRetinaに向かうであろう以上、ソフトウェアの側でも対応は進んでいくとは思いますが。
・やっぱり高い描画負荷？
随所で言われていますが、例えばブラウザをスクロールさせるとMacらしからぬ引っかかりを感じることがあります。CPU内蔵グラフィックスには2880x1800の描画は荷が重いのかとも想像しますが、実際のところどうなんでしょう。NVIDIA固定で解消されたりするのかしらん。
・IPSで広視野角、反射は非Retinaより少なめ？
IPSパネルなので視野角は広いです。例のパイプしまくっているコマンドを叩いてみましたが、製造メーカーはわかりませんでした。噂によるとLG製のものがあるらしいです。特にぎらつき等は感じず。例によってピカピカパネルですが、従来機より反射が抑えられている感じはしました。非光沢オプションが欲しかったところですが、画素が細かくなると適した表面処理とかも違ってくるのかも。
・まっすぐなLUT
我々が気にしなくともディスプレイの色味を調整してくれているColorSync。デフォルトのカラープロファイルを見ると手元のAirなんかえげつないLUTが書き込んであるのですが、展示されていたRetinaモデルのLUTはまっすぐでした。Apple的にはパネルの素性が十分いいということなのでしょう。ぱっと見赤いとか青いとかはありませんでしたが、細かい表示は未確認、色域も少なくとも狭くないのはわかりましたが、未確認。ま、ITMediaさんあたりがキャリブレータ使ったレビュー記事を出してくれるはずなので待ち。
買い換えるなら間違いなくRetinaにするでしょうが、メインの交替はもうしばらく先でいいかなあ。とりあえずAir触り始めてからメインのProもSSD化したい今日この頃。
うまく表示できない添付ファイルが読めるかもしれない方法
メールの文字化けや添付されたテキストファイルの文字化け。たいていは文字コード云々で解決しますが、添付ファイルだけが文字化けして意味不明な記号列になっている、ファイルが破損しているようで読めない、という場合もあります。そんな場合でもテキスト系のファイルくらいならひょっとすると読めるかもしれないというお話。
メールにファイルを添付するときには、画像でも何でも決まった型式でテキストに変換して送信されています。今回対象とするのはMIME Base64でエンコードされていて、なんだかデータが乱れてしまっている場合。
やることは単純で、メールのソースを手でデコードしてあげます。手順はこのあたりを参照。
まずはメーラーでメールのソースを表示。例えばThunderbirdだと表示ーメッセージのソースと選択すれば表示されます。ずるずるとスクロールしていくと、Content-Transfer-Encoding: base64とかfilenameなんとかの文字列の後に意味不明な記号列がずらずらと並んでいる部分があると思うので、そいつを適当なテキストファイルにコピペします。データが乱れてしまうのは基本的にファイルが複数あるときだと思うので、これは複数回、場合によってはファイルの数の2倍くらいの回数やる羽目になるかもしれません。
次に、こいつをデコードします。Perlでできるみたいです。Perlは使ったことがないのですが、先程のリンク先のままやったらできました。例えばhoge_mime.txtに保存したとすると、テキストファイルとして吐き出す場合は
perl -MMIME::Base64 -ne print decode_base64($_) hoge_mime.txt > hoge_mime_result.txt
テキスト系のファイル（プログラムのソース他）ならこれで読めるはず。先日出くわしたメールではテキスト系ゆえ中身でわかったのですが、メールのソースに書かれたファイル名と中身との対応が崩れてしまっていました。
対応が乱れていない場合にはjpeg等のバイナリファイルも復元できるでしょうが、対応が崩れてファイルが砕け散ったりしている場合には一筋縄ではいかないかもしれません。
あと、ファイルの数が多いときにはめんどくさいです。MIME Base64部分の切り出しから変換までスクリプトを書いてしまった方がいいかも。そこまでして復元する前に再送をお願いした方が手っ取り早いですが…
MX130 S1にRadeon HD 6570を増設してみる
10日になりましたが、新年明けましておめでとうございます。今年もよろしくお願いいたします。
さて、Windowsマシンとして順調に稼働中のMX130 S1、新年早々skyrimでもやってみようかと思い立ち、さすがに785Gオンボではきつかろうとグラフィックボードを増設してみました。縛りは250W電源(12V 18A)にロープロ。6670も考えたのですがロープロ1スロットだとうるさそうに見えたので、性能差はあるものの消費電力的にも安心感のある6570にしました*1。買ってきたのはこれ。DDR3ながらさりげなくVRAM2GBですが、クロックが800MHzに落とされています。明確にロープロファイル対応は謳っていませんが、箱にロープロ用ブラケットが入っている旨のシールが貼ってあります。
なおPCI Express x16の隣にはスロットがなく2スロットタイプもささりそうですが、クーラーがごついとボード長によってはマザーのコネクタと干渉してしまうかもしれません。HISのデュアルファン6670は気になったのですが長さが書いてなかった…
脱線はさておき、買ってきたボードを取り付けます。ブラケットはデフォルトではノーマルタイプのものがついているので、ロープロ用に交換。交換の際VGAとDVIの横のねじはペンチか何かでつまんで回す必要があります。またVGAを使いたい場合は追加のブラケットが隣接のスロットを塞ぐので注意。BIOSの内蔵グラフィック設定はデフォルトのままAutoでOK。
あくまで主観ですが、静音性は結構いいと思います。元々HDDを1本増設してあることもあり、音源が増えた感じはしますが特にうるさくなったなあという感じはしません。比較対象がアレですが、DELLのOptiplexについてたロープロRadeon HD 2400 XTよりは静か。
せっかくなので、ベンチでも取ってみます。とりあえず現在の状況をまとめると
| CPU | Phenom II X4 905e に換装 |
| メモリ | Corsair CMX8GX3M2A1333C9 (4GBx2) を増設*2 |
| グラボ | SAPPHIRE HD6570 2G DDR3 PCI-E HDMI/DVI-D/VGA を増設 |
| HDD | WesternDigital WD20EARX を増設 |
| その他 | KEIAN KTV-FSPCIE を増設※ |
※PCI Expressスロットには固定不能*3
以下スコアです。常駐まんまとか測定はいい加減につき、参考程度にどうぞ。スクリーンショットじゃない辺りにやる気のなさがにじみ出ています。CINEBENCHだけオンボのデータを取ってあったのでそれも掲載。
| 3DMark11 | Graphics | Physics | Combined |
|---|---|---|---|
| P1284 | 1163 | 3406 | 1117 |
| 3DMark06*4 | SM2.0 | HDR/SM3.0 | CPU |
| 7813 | 2784 | 3342 | 3533 |
| PCMark7 | |||
| 2008 | |||
| CINEBENCH R11.5 | CPU | OpenGL | OpenGL@Radeon HD 4200 |
| 2.94 | 36.49 | 4.25 |
省電力版CPUと組み合わせるとこのくらいになるということで。エントリーGPUだと3DMark11はさすがにカクカク。でも素の状態のskyrimは自動判定でultra high設定になりました。最新のゲームでも軽いものなら十分動かせるようです。
VRAMは1GBのものでよいと思いますが、限られた電源容量やスリムケースの範囲ではよい選択肢かと。
CDDBは手焼きの味を知っている
iTunesにCDを食べさせるとネットワーク経由でそのCDの情報を取り込んでくれますが、これに使われているGracenoteという会社のCDDB、カバー範囲は相当なようです。
- ちょっとマイナーかもしれない普通のCD→当然OK
- ならば同人作品（とはいえショップなどで広く流通しているもの）→普通にOK
- さすがに10年近く前の幻の手焼きCDとか…→知ってますが何か?
っと…未だにこいつにこのCD知らんわ、と言われたことがありません。どうやら仕組みとしては有志の入力情報を集積することで成り立っているらしく、したがってどこぞやの誰かが先にPCにCDを突っ込んだりして情報を入力していてくれればヒットするみたいです。情報にばらつきがあったり微妙に間違っていたりするのはご愛敬ですが、なかなか恐るべしシステム。
CrystalDiskMarkいろいろ
なんだか消化不良なので、適当にベンチをば。あまり役に立つ情報はありません。測定もいい加減につき。
まずはST3250318AS。ごく普通の7200rpm、250GBのHDD。Windowsで使用中。
続いてWD20EARX。倉庫用ドライブのスタンダード。低回転ながら大容量と大きなキャッシュのおかげで？システムドライブより速い結果に。SATA2.0環境だけど、3.0は多分不要。Windowsでデータドライブとして使用中。
ここからは面倒なので測定サイズ100MBで失礼。
IS12SHに付属のMicroSD。Buffalo製BSCRA32U2にて測定。SD-C02G TAIWANとあり、Google先生によれば東芝の台湾製とのこと。リードはカードリーダで律速してるかも。ごっそり使用中。
IS12SHのカードリーダモードだと残念な結果に。
以下NortonのAuto-Protect切って測定。
パナのClass4日本製SD2GB。ちょっとだけ使用。こちらもリードはカードリーダ律速かも。
3年くらい前の東芝MicroSD日本製1GB。軽くフォーマットして測定。シーケンシャルリード/ライトは寂しいがランダムライトはむしろ上記二製品より上。やっぱりフラッシュメモリは単純ではないです。
数年物のサンワサプライ製UFD-RH2G2、SLCをうたう2GBのUSBメモリ。SLCにしては4Kライトが出てないような気もしますが、最近の下手な廉価USBメモリよりは高速かも。ただ、端子のギミックはいらなかったような。
おまけ？秋ももう終わりですが。
秋空の下の富山城跡前の広場。
あくまで富山城跡。現在は資料館が。
IS12SHにSanDisk 32GB MicroSDHC Class4を入れてみる（ベンチはなしです）
何気に音質のいいIS12SH。手元の楽曲データもCDからリッピングしたDRMなしがほとんどだし、付属のMicroSDに転送して少しテストしてみたところバッテリーも食わなさそうだったので、古いiPodの後釜に据えてみることにしました。
というわけで大容量MicroSDHCにアップグレード。楽曲データが13GB程度あるのでClass10の16GBとClass4の32GBで迷いましたが、まあスマホ程度ではClass4でもそんなに変わらないだろうという見込みで、容量を取って32GBに。モノは石橋を叩いてSHARPでも検証済みのSanDisk Class4。Lexarは32GBでClass10がありましたが、最近発売されようとしているSanDiskの高速タイプでもClass6止まりなのを考えると、価格差もありちょっと回避。
さて、意気揚々と買ってきたはいいものの、こいつ、結構難儀しました。
まずは1枚目。フォーマット済みを確認し試しにUSBカードリーダ（Buffalo製BSCRA32U2)にさしてWindowsサブマシンでCrystalDiskMarkでもとってみようかと思ったらPreparingのまま停止。Windowsで再フォーマット（後で考えてみればこれがこの後の結果に影響した可能性も）するも同じ。カードリーダを疑いIS12SHにさしてフォーマット、カードリーダモードで試すと512KBランダムライトでエラーを吐く。NortonのAuto-Protectを切っても変わらず、Windowsでの再フォーマットがこける、USBのアンマウントができないなどの現象が発生。IS12SHでのフォーマットは何回かやっても問題が起きなかったので手元のWindows環境との相性を疑い、とりあえず楽曲を転送してみることに。が、8GBくらい問題なく転送したところでエラーが発生。USBカードリーダに差し替えてみるもそれ以上転送できず、マウントが解除されてしまうなどしたため、初期不良でも引いたかと判断して交換してもらいました。
そして2枚目。いろいろ調べたところSD Association謹製のフォーマッタを使えとのお告げがあったので以後そちらでフォーマット（ちゃんとMac版もあります）。が、2枚目もCrystalDiskMarkはうまく走らず。IS12SHで楽曲転送したところ13GBに対して3回エラーが発生したものの、今度はマウント解除にはならず当該ディレクトリを削除して再転送に成功。
バリデーション済み構成にしてはいささか不安定な気はしますが、2枚連続で初期不良を引いたというよりは諸々の相性が絡み合っているという線の方があり得るかなあ、と結論してしばらく使ってみることにしました。まあ適宜写真くらい吸い上げておけば特に消えて困るデータを入れるわけでもなし、メーカーの5年保証はあるので不具合が出れば交換してもらえるはず。
次世代スパコン2種
富士通とNECからスパコンの話が出てきました。
富士通の方は京の正常進化版を来年1月から出荷開始という話。CPUは45nmから40nmにシュリンクしてコア数を16へと倍増、SIMD命令を拡張といったもののようです。理論演算性能も消費電力もコア数に従ってアップしています。理論メモリ帯域は64GB/sから85GB/sへとクロックアップ風味。ノード写真のメモリの刺さり方からするに8chDDR3-1333でしょうか。とすると京のチップは同じDDR3-1333で6chだったとすれば計算が合います…と言いかけましたが写真を見ると京も同じ刺さり方…適当にググった範囲では書いている資料がなかったのでなんとも言いようがないですね。
水冷周りを含む実装技術やソフトウェア技術では、京を作ったノウハウが活かされていることでしょう。個人的にはCPUがハーフノードなのが微妙に気になりますが、やはり32nmともなると開発がしんどいのでしょうか。というかまあ、ひとりで32nmから22nmにいこうとしているIntelが化け物なわけですが。
一方のNECの方はもう少し先で2013年あたりに製品化というお話。ええ、SX-10?ついに登場です。SX-9で実装が物理的に限界に達したのか、次回作はSoCとまではいきませんが、かなりの部分をワンチップにまとめるようです。マルチコア構成で、理論性能はコア当たり64GFLOPS、理論メモリ帯域はコア当たり64GB/sという数字が出てきています。SX-9では16CPUのノードで1894.4GFLOPS・4TB/sだったので、単純なメモリ帯域/演算性能比で言えば半分くらいの勘定。プレスリリースではコア間の通信、同期処理にも気を配る旨書かれていますが、なによりSX-9の醍醐味であり肝だった?頭のねじが1本取れているとしか思えない（こんな感じ*1）プログラムに有無を言わせないメモリ接続が一体どうなるのかが気になります。
さすがにチップ内に3次元ですさまじい配線でもやらない限り、ベクトルマシンとは言いつつもスカラーマシンとの中間的な構造に落ち着きそうな気はするのですが、はてさてどんなものが出てくるのか、ちょっと注目。
