Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7

CPU：HaswellとオプションのCrystalwell

21.5inch iMacのエントリーモデルは最も手の届きやすいMacの一つである。15万円でAppleのノートを
買おうと思ったらデュアルコアになるが、こちらは65W Core i5-4570R、クアッドコアだ。4つのコアが
2.7GHzで動作し、Turbo Boost時には最高で3.2GHzまで速度が上がる。実際のところは、負荷に関係なく
ほとんどいつも3.0GHzで動作しているところを見る。3.1GHzくらいまで冒険するのを見てみたいのだが、
実質ほぼ3GHzで動作するHaswellモデルと考えて良い。

モデル名の末尾のRは特別仕様であることを示す。単にIntelの最速GPU構成（40EU/最高1.15GHz）である
だけでなく、128MBのオンパッケージeDRAMまでも手に入るのだ。これら2つの組み合わせが、新たに
名前を与えられたIntelのIris Pro 5200である。

Intel Iris Pro 5200は15inch MacBook Proでも見てみたいGPUの構成であるが、iMacに載せられた
ということで、いかなるものなのかが伺い知れる。昨年のモデルのiMacでは、AppleはNVIDIAの
ディスクリート型GPUから選んで搭載していた。でも今年のiMacでは、上位機種がすべてNVIDIA Kepler
ディスクリート型GPUを搭載するのに対し、エントリーモデルはIris Pro 5200を搭載している。この分け方は
15inch MacBook Pro Retinaディスプレイでも行ってほしいものである。我々のIris Pro 5200のプレビューでも
示した通り、最速の構成であっても、NVIDIA GeForce GT 650M（これは2012年モデルの15inch r-MBPに
搭載されている）の性能を凌駕するには至っていない。Appleのエンジニアは性能を旧型より低下させることを
殊に好まないから、GPU性能を求める向きにはNVIDIAのディスクリート型GPUを残したが、我々は一体型GPU
としてはIntelでは初めて、真にまともな選択肢を得たのである。
（訳註：従来のIntel HD Graphicsなど、Intelのチップセット一体型はそれ単体ではロクなものではなかった、
ということを暗に示しています。一方でNVIDIAの一体型はGeForce 320Mなど充分な性能のものがありました）

一方、（訳註：Windowsの）OEM PCメーカーの行き方は全く逆を行っているようだ。彼らはIntel Iris Pro
よりもNVIDIAのローエンドディスクリートGPUを好んで採用している。コストという点では両者はほぼ同等だ
（Intelの方がわずかに有利なようだが）。NVIDIAの方が性能は上だが、Intelは省電力であること、ロジック
ボードに占める面積が明らかに小さい。おそらくIris ProはAppleの期待よりも速度がやや遅かったのではないかと
思うが、Iris ProはAppleがIntelに設計を依頼したことからも、他に転用されるのは屈辱的なことであるとAppleは
考えたのではないだろうか。加えて戦略面でも合点のいくものである。もしAppleがプロセッサ・グラフィック
だけを考えて設計をするようになったとしたら、ロジックボードと省電力設計の見直しを行うことになり、
製品のデザインそのものにも多大な影響を与えていたであろう。それは我々自身もまだ望むところではない
（訳註：昨年全面的にデザイン変更をしたばかりなのに、ということを暗に言っています）。そちらの方向に
進むかどうかは、Intelがどのくらい大胆にグラフィック重視に振れるかにもよる。

先に筆者は128MB eDRAM（コードネーム：Crystalwell）についてちょっとだけ触れた。簡単に言えば、これは
CPU/GPU両方においてL4キャッシュの役割を果たす巨大なオンパッケージメモリである。双方向で50GB/sもの
帯域幅を持ち、アクセス・レイテンシはL3キャッシュとメインメモリへのリクエストの中間くらいである。

OS XはCrystalwellの存在を認識してはいないようだが、確かにそこにあり機能している（後述のGPU性能
テストの結果を見ればお分かりいただけるだろう）。一部の特定の負荷に関しては大容量のeDRAMの素敵な
恩恵を受けることができる。起動時、OSの主要部分はオンパッケージのキャッシュ上にも展開されると筆者は
見ているが、これはモバイル時のパワーユースにおいて特に大きく影響を受けるところだろう。残念ながら
本レビュー機はハードドライブ搭載機種であり、新型iMacは分解が簡単ではない（言うまでもなく、レビュー機に
そういう行為を行うことに関してAppleはいい顔をしない）ことで、ユーザエクスペリエンスに負の影響を
与えてしまっていた。OS Xはメモリ上にキャッシュする方法に関してはずっと長けており、本レビュー機の
iMacのデフォルトの8GBメモリ構成においてはものすごく役に立っている。メモリ上のデータやアプリに
アクセスするときは、システムは常に非常にキビキビとしていた。ベンチマークは後ほど。

OS X環境下でのIris Proのゲーム以外でのエクスペリエンスは非常に良好であった。OS X 10.8.5のSafariで
グラフィック上の問題（iCloudのタブの長いリストをスクロールする際、コンテンツがちぎれて見えた）こそ
あったものの、それ以外は良好だった。

Intelはいつもそうであるが、タダでは飯を食わせてくれない。128MB eDRAMを載せた代わりにL3キャッシュの
サイズは4MBと小さく、しかも4つのコア（さらにはGPUまで）で共有だ。この代償は実はハイエンドの
Core i7 Rシリーズでも同じであるが、L3キャッシュの容量は6MBといくらかマシだ。コア数とL3キャッシュ
容量の比はどの最近のIntel Coreシリーズプロセッサよりも悪いのだ。128MB eDRAMはこのL3キャッシュ
容量の削減を埋め合わせて余りあるものだが、今後のIntelはこの方向に進むという予兆ではないだろうか、
と筆者は考えてしまう。大容量のeDRAMがバックにいれば、小容量でレイテンシも低いL3キャッシュを
搭載する方向に進むことも理に適っているのではないかと。


2ページ目以降は後日。

このｽﾚの存在忘れてた
乙です

>>777
(´･ω･`)b GJ!

昨日の続き。2ページ目いきます。
ttp://www.anandtech.com/show/7399/215inch-imac-late-2013-review-iris-pro-driving-an-accurate-display/2
のグラフを見ながらどうぞ。

CPUの性能

さてこのエントリーモデルのiMacを、我々の通常のOS Xテストスイートに供してみた。筆者はデスクトップ
Macのテスト結果を山ほど持っているわけではないが、昨年のモデルの27inch iMacのものならある。
ここから敷衍して見ていこう。また、比較対象機種がほぼすべてSSD搭載機なのに対して、今回のレビュー機の
21.5inch iMacはHDD搭載機であることをまず念頭に置いて読んでいただきたい。

シングルスレッドのパフォーマンスは13inchのHaswell搭載MacBook Airとほぼ同等だ。考えてみればこれは
ちょっととんでもないことだ。この13inch MacBook AirはオプションのCore i7搭載機で、Turbo Boost時3.3GHz。
対して今回のエントリーモデルのiMacはCore i5を搭載し、Turbo Boost時3.2GHz。一つのコアに割り当てられる
L3キャッシュの容量はどちらも同じ(4MB)。Cinebenchの場合、128MBのL4キャッシュはあまり役に立って
いないようだ。

マルチスレッドのパフォーマンスとなるとMacBook Airより明らかに良くなる。今回のエントリーモデル21.5inch
iMacのパフォーマンスは、図に示す通り、私の古い2011年の15inch MacBook Proと非常によく似たものと
なっている。Core i5-4570RはIPCとTDPがより高いが、デスクトップ向けCore i5ゆえにハイパースレッディング
には対応していない。したがって4コア4スレッドだ。私の古いMacBook ProのCore i7は4コア8スレッドであり、
マルチスレッド化が進んだアプリケーションにおいて各コアの実効リソースをより有効活用できる。これは
Appleには何の責任もないことだが、Intelのラインナップのセグメンテーション戦略の副作用でもあり、
フラストレーションが溜まる話だ。

iMovieテストでは、昨年のハイエンド27inch iMacの方が今回のエントリーモデル21.5inch iMacより約50%
高速である。これはTurbo Boost時のクロック周波数の差と、同時に処理できるスレッドの数の差と説明できる。
それと今回のレビュー機はHDD搭載機であり、対するに比較対象はSSD搭載機であるという違いもあるのだが、
このOS X CPUテストスイートではIO性能の影響が最小限で、CPU性能に大きく依存するものである。
（訳註：それゆえHDDとSSDの違いはここでは無視してよい、ということを暗に言っています）

iPhotoのインポートテストも、ここまでのテストとほぼ同じ傾向だ。エントリーモデル21.5inch iMacは充分な
性能を有しているが、パワーユーザーは必ずや、より速いCPUを求めるであろう。

本章で最も興味深い結果を示すのはLightroomのエクスポートテストかもしれない。3.4GHz Core i7と
Core i5-4570R＋Crystalwellの性能差はわずか12%しかないのだ。筆者は当初、この差の縮小はCrystalwellが
もたらしたものだと考えていた。だが、1.7GHz 2013 MacBook Airと本iMacとの差は、iPhotoにおける
両者の差とほとんど違わないのだ。そこで筆者は、ここでの結果は、Haswellのアーキテクチャ上のアドバンテージが
光るベンチマークのもう一つの例であると考えるようになった。

Photoshopでの性能も同様に良好だ。本iMacは昨年のハイエンド27inch iMacの性能に比較的近い。
（性能差は20%以内）

Final Cut Pro Xのテスト結果も特に驚くべきものではなかった。

Xcodeのテストで興味深いのは、HDD搭載機であるがゆえに、21.5inch iMacのパフォーマンスにいかに
一貫性がないかということだ。実行回数を重ねたとき、パフォーマンスは同等であったり、ビルド時間がずっと
悪くなったりした。オプションのSSDを選ぶ理由を探す必要があるのなら、このテストなどうってつけだ。
最高の性能を発揮できたときでさえ、MacBook Airよりも素晴らしく高速とは言えないことが分かる。
SSD搭載機であればパフォーマンスははるかに上がっていたはずだ。

（2ページ目は以上。続きは明後日以降！）

ワッフルワッフル

もしかして需要ない？と思いつつも3ページ目。

GPUの性能：荒ぶるIris Pro

新型iMacはかなり良いが、今回のレビュー機に惹かれたのは、Intel Iris Pro 5200グラフィックスを初めて搭載
したマシンの一つであることだ。実は、今回のエントリー機種iMacと今年始めにテストしたIris Proには、いくつか
大きな違いがあるのだ。

我々はCore i7-4950HQ、すなわち2.4GHz 47W（Turbo Boost時最大3.6GHz）、L3キャッシュ6MB＋128MBの
L4 eDRAMを搭載したクアッドコアをベンチマークテストに供した。￥138,800で購入できる21.5inch iMacの
エントリー機にはCPUのオプションが用意されていない。CPUはCore i5-4570R、すなわち2.7GHz 65W
（Turbo Boost時最大3.2GHz）で、L3キャッシュは4MBしか搭載していない（eDRAMは128MBだが）。
4570RはGPUもTurbo Boost時1.15GHzで、4950HQの1.30GHzと比べるとこれまた低い。すなわち、ここから
予想できるのは、今夏我々がテストした4950HQと比較して、今回のiMacは全般的に性能が下回っているだろうと
いうことだ。また、発売時にはAppleがIris Proに提供したBoot Campドライバーはかなり古いバージョンで、
筆者はWindowsでテストする前に最新のドライバーにアップデートしておいた。
（図：左が出荷時のドライバーバージョン、右が最新のドライバーバージョンであろう）

それでも、Iris Pro 5200のパフォーマンスは驚くほど優秀なのだ。Broadwellでは更にパフォーマンスが向上する
ことを筆者は期待しているし、その次の世代でもおそらくIntelは同様な歩みを続けるだろう。とはいえ、筆者は
Intelの第7世代グラフィックスにはダイ面積辺りの効率において確かに懸念もある。普通ならばmm^2あたりの
パフォーマンスなど気にも留めないのだが、Intelの場合、どれだけダイ面積あたりのパフォーマンスに気を遣って
いたかということを考慮すれば、確かに懸念点なのだ。

比較対象の中で注目すべきはGT 750Mだ。というのも昨年モデルの21.5inch iMacのエントリー機が搭載していた
GT 640Mとほぼ同等の性能だからだ。いくつかの例外を覗けば、新型iMacに搭載されるIris Pro 5200はGT 750Mと
ほぼ遜色のない性能を示している。ただし、いくつかの項目においてはかなり大きな差がある。この点については
我々は以前にIris Proのレビューを行ったときにも気付いており、いくらモバイル用がメインといえども、Intelが
NVIDIAと張り合うつもりであるなら、ドライバーの最適化に本気で取り組む必要がある。たとえばMetro。
低解像度での結果は素晴らしいが、解像度と画質を上げたときはGT 750Mの方が遙かに上だ。Sleeping Dogsも
同様だが、ここでの差の分は、高画質設定においてAA処理がONになっていることから来ているようだ。同様に
Bioshock Infiniteでは全般的に大きな差が見られる。ただし、Tomb RaiderやSleeping Dogs（AA処理OFF）では、
Iris ProはGT 750Mよりわずかに劣るだけだ。新型iMacではGT 750Mはおそらく更に高速になっているであろう。
グラフィックメモリがDDR3からGDDR5に変更されたからだ。（訳註：21.5inchの上位機種のこと）

AppleがHaswellの製品ラインナップの中からiMacのエントリー機種にIris Pro 5200を選んだ理由が、コスト優先であり
パフォーマンス優先ではないことは明らかだ。Rシリーズのハイエンドのオプションも見てみたかったのだが、
そういう選択をする人は少数派なのだろう。

これらの表は、Iris Proのパフォーマンスと、15-inch rMBPほかのディスクリートGPUの比較だが、実際の
プレイアビリティとなると何を意味するのだろうか？　筆者はOS XでBorderlands 2を1080p、画質設定を最高
（AA/AF処理ONも含め）にしてプレイしながらフレームレートをプロットしてみた。iMacのネイティブ解像度での
全体的なエクスペリエンスは非常に良好だった。

一度一桁台のfpsに落ち込んだ（なお、これがHDD由来なのかどうかははっきりしない）以外は、常に30fps以上で
プレイすることができた。

BioShock Infiniteにて、OS X対Windows 8のゲーム性能の比較を実際にやってみた。

OS X 10.8.5対Windows のゲーム性能 - Bioshock Infinite
1366 x 768 Normal Quality 1600 x 900 High Quality
OS X 10.8.5 29.5 fps 23.8 fps
Windows 8 41.9 fps 23.2 fps

驚くにあたらないことだが、GPUにあまり依存しない条件下では、OS XとWindowsではゲーム性能にかなり大きな
差がある。過去に一部のデベロッパが不満を漏らしていたのだが、低レベルのAPIアクセスが欠如していること、
それとOS XはDirectXをサポートせずOpenGLを用いなければならないことが原因の一部だ。その代わり、最も
GPUに依存するテストでは、OS XとWindowsのパフォーマンスはほぼ同等だ。少なくともBioShock Infinite
についてはそれがいえる。


3ページ目は以上。実は4ページ目と5ページ目こそが、訳したいという衝動に駆られた要因なのですが、うｐには時間かかるかも・・・

>>785
(´･ω･`)b GJ!

乙。
Iris Proとはなんぞ？と思いつつIntelのGPUには悪いイメージしかなかったので、
詳しく調べようとは思わなかったけど、なかなかよさそうなんだね。
ディスクリートGPUが搭載されてないMac miniにこれが搭載されれば使い勝手のよいマシンになりそう。

4ページ目行きます。

ストレージとFusion Drive

iMacは標準状態では全機種メカニカルハードドライブ（21.5inchは2.5inch、27inchは3.5inch）を内蔵している。
筆者はHDDのみのシステムを使うことを自らに課してからしばらく経つが、HDDに戻ることで、かねてから
考えていたことを再び肯定することとなった。HDDのみのシステムをはPC業界を殺してきていた、と。HDDの
エクスペリエンスはとにかくよろしくない。OS Xはよく使うデータをメインメモリにキャッシュすることにおいて
非常に良い仕事をしてきたし、今回のiMacが標準で搭載する8GBというメモリ容量はその目的には十分である。
したがって HDDのみのオプションにも、すぐに我慢はできるレベルとなった。しかしながら、筆者の考えでは
「我慢はできる」レベルを目指すのは志が低いのだ。

iMacは標準状態でHDD搭載の状態で出荷される数少ないMacの一つであり、その点では異色だ。MacBook Airと
MacBook Pro (Retina Display)は全機種SSD搭載で、来るべき新型Mac Proも同様である。AppleはiMacについて
これらの機種とは別のユーザー、すなわち大容量の単一ドライブに慣れたユーザーをターゲットとしているという
のが筆者の推測だ。

Appleは二つのドライブをユーザーに使用すること（あるいは、高速で小容量のローカルストレージと、それ以外を
全部クラウドに保存すること）を強いることなく、この問題への解決策をたぶんだいぶ前から提供している。それが
Fusion Driveだ。

2012 iMacで筆者はAppleのFusion Driveをじっくり分析した。したがってここでは詳細に触れるのは割愛する。
高レベルにおいて、Fusion Driveは、128GB SSDと1TB/3TB HDDの上に位置し、SSDの「キャッシング」を
ソフトウェア管理下で行うソリューションだ。ここで「キャッシング」をカギカッコでくくったのは、実際には
Fusion Driveはキャッシュとしてふるまうのではなく、ソフトウェア管理下で拡張ストレージボリュームとして
ふるまうためだ。Fusion DriveはSSDとHDDの容量の合計に相当する単一のボリュームとして表示され、
どのデータをSSDに置きどのデータをHDDに置くかを、ソフトウェアレイヤーが賢く管理している。
Fusion Driveは、一台のコンピュータに小容量のSSDと大容量のHDDが搭載されているときにあなたが手動で
行うであろうことに近いことをやっている。あなたはよく使うアプリケーションをSSDに、そうでないものは
すべてHDDに保存するであろう。違いといえば、Fusion Driveはブロックレベルでストレージの管理を行って
いるのに対し、あなたはファイルまたはアプリケーションレベルでデータをドライブ間で移動していることだ。
理論的には、あなたが管理しているものがもし128GB SSDにすべて収まるのであれば、Fusion Driveは手動で
管理するSSD＋HDDのハイブリッド構成と区別がつかないのだ。

実際のテスト条件下では、AppleのFusion Driveは、SSD＋HDDのハイブリッド構成の中では最もSSDに近い
エクスペリエンスを得られる。理由はきわめて単純だ。AppleのFusion DriveはI/Oの圧倒的大部分をキャッシュ
するのに充分な容量のNANDを搭載しているからだ。世の他のほとんどのハイブリッドドライブでは、SSDの容量は
8GBから32GB程度だが、Fusion Driveは128GBのみだ。今年のiMacのアップデートでSSDの容量が256GBに
増量されなかったのはややがっかりだが、筆者の128GB/1TB Fusion Driveはこの一年非常に良好であった。
NANDの価格低下に合わせて、Appleが来年のモデルのiMacでSSDの容量を256GBに増量するか、あるいはその
代わりにFusion Driveを標準で選べるようにするかは興味津々である。

個人的な好みを言えば、大容量のSSDと外付けの大容量HDD（できればThunderbolt経由）の組み合わせが好きだが、
単一のストレージが必要ならば、是非Fusion Driveを選んでほしい。昨年Fusion Driveの評価を行ったときに同様の
ことを書いたが、考えてみればこのカテゴリーに入るユーザーはさほど多くはないのだ。筆者が間違っていた。

この一年、筆者は、姉(妹)夫婦にどのコンピュータを薦めるかを検討していた友人と、ほぼ定期的に語り合っていた。
友人の姉(妹)夫婦は二人ともMacユーザーで、筆者は13inch MacBook Pro (Retina Display)を推していたのだが、
友人は少なくとも1TBのストレージは必須であり、それは内蔵のドライブでなければならないと反論してきた。
こうした理由付けも虚しく、彼らは二人とも最終的に13inch MacBook ProのHDDモデルを選んだ。筆者はそうした
人たちを説得したがる口だが、昔ながらの習慣は簡単には変えられない多くの人たちのことも理解しているつもりだ。

新型iMacでは勿論Fusion Driveを選ぶことができるが、オプション価格は2012年モデルの下位機種と比べて$50
下がった。率直に言って、iMacを購入するユーザーにとってはFusion Driveは最低限の必要条件であるべきと思う。
Appleがこれらの機種に標準でHDDを搭載する理由は理解しているが、どうせ買うなら一気にFusion Driveに
アップグレードしたくなるはずだ。

Fusion Driveを選ぶと21.5inch iMacの下位機種の価格は￥160,800に上がり、同じ価格で256GB SSDを選ぶ
こともできる。どちらを選んでも結構だが、少なくともそのどちらかは選ぶべきだ。たとえターゲットユーザーが
別のところにあったとしてもだ（訳註：一般人はHDDを選ぶかもしれないが、少なくともFusion Driveか256GB
SSDにしてほしい、ということを暗に示しています）。筆者は長年、SSDが伝統的なHDDよりいかに優れているかを
詳しく語り続けてきたので、ここではこれ以上言及しない。でもエクスペリエンスは朝な夕なに感じるものだし、
率直に言って、現代のコンピュータではSSDが必須であると筆者は言いたい。


4ページ目終わり。5ページ目は・・・明後日かな・・・？

>>790
(´･ω･`)b GJ!

5ページ目。
ttp://www.anandtech.com/show/7399/215inch-imac-late-2013-review-iris-pro-driving-an-accurate-display/5
の図を見ながらどうぞ。

ディスプレイ

今回のiMacが最初に発表されたとき、筆者は21.5inchには肩をすくめた。当時筆者は27inchのThunderbolt Display
を使っており、それよりもサイズが低い、あるいは解像度の低いディスプレイを使うなんぞ考えてもいなかったのだ。
ところが27inch iMacが昨年モデルの全くの正常進化系に見えたのに対し、筆者は新型21.5inchに興味を惹かれた。
Intel Iris Pro 5200グラフィックスゆえだ。というわけで何年か前に30inchの2560 x 1600ディスプレイを使い
始めて以降初めて、3Megapixel以下のディスプレイを使うに至ったのである。

このところノート型のディスプレイと共にどれだけの時間を過ごしたかを考えると、今こそ1080pのデスクトップ型
液晶に戻るのに適した時期はなかった。筆者は超高解像度が大好きだが、AppleがデスクトップモデルもRetina化して
21.5inchに4K液晶を（あるいは27inchに5K液晶を）投入するにはまだ時期尚早なのだ。

21.5inchを選ぶか27inchを選ぶかとなると、二つの理由が存在する。コストとサイズだ。吊るしの下位機種同士の
比較で21.5inchと27inchとでは￥51,000の価格差がある。まずこの時点で充分な価格差が存在する。サイズも
同様に理解しやすい。27inchはデスクを広く占領してしまうし、必ずしもすべての人がこの広大な画面に囲まれるのを
好むわけではないことも筆者は気付き始めていた。いすれにせよこのサイズ、この解像度をもつコンピュータに
おいては、明らかにそれに向いた市場が存在する。で、液晶の品質はそれに見合うものなのだろうか。

早い話、ほとんど完璧なのだ。

Brianと筆者は、同時期に取り組んでいたお互いのレビュー記事を見せ合っていた。彼は筆者に、テスト機の
ディスプレイの色の再現性の高さを示しながら、CIE色度図を送ってくれた。筆者はこのように返信した。

（図：21.5inch iMac (Late 2013) 色度図）

ここで□は理想値、それに対し○はディスプレイの表現色である。21.5inch iMacのディスプレイは箱出しの
状態でかくも正確で、キャリブレーションも一切不要なのだ。これに対するBrianの返信は、

凄いな
箱出しでこれかい？

iMacのディスプレイは我々のテストすべてにおいて極めて優秀な結果を示した。ΔEが常に2以下だったのだ。
まったくもって信じがたい。我々が持っているタブレットのベンチテストデータをちょっと拝借して、そこへ
リファレンスとして2013 MacBook Airを投入してみた。

21.5inch iMacの下位機種のターゲットユーザーをイメージングのプロとAppleが設定していたとは考えにくいが、
21.5inch iMacは仮にそうしたプロが使っても見事に使いこなせ、しかも完全に満足する出来であろう。もはや
欠けているのは倍の解像度を持つ液晶のみという状態だが、それが登場するのはもう一年以上先のことだと、
筆者は推測している。

ここで一点補足しておかなければならないのは、Appleは通常液晶パネルを複数社（通常は2〜3社）から
仕入れているということである。勿論、ロット間におけるパネルの品質の差というのも言うに及ばないことだ。
本レビュー機よりももっと優れたパネルがいくつも存在するとは思わないが、市場に出回る製品の中にはこれより
品質の悪いパネルもあることだろう。とはいえ、これまでAppleのパネルでは色の再現性に大きな差があったこと
などなかったことから、新型iMacを買ったユーザーは、素晴らしいディスプレイに出会えるだろうと筆者は断言できる。

5ページ目は以上。
21.5inchの液晶の色再現性の高さにびっくりという感じでしょうか。

6ページと7ページはさほど面白いわけではないのですが、ここまで来た以上全部やっちゃいます。
後日になりますけどねｗ

とても参考になります。

ワッフルワッフル

さーて残り全部一気にやっちゃいますよ。6ページと7ページ。

WiFiとIO

新型iMacは2013 MacBook Airに続いて802.11acをサポートするようになった。だが、MBAの
実装方法とは異なり、iMacの場合は3アンテナ/3ストリーム構成であり、更に高いパフォーマンスを
発揮できる余地がある。802.11ac対応の新型AirMac Extremeとの組み合わせでは、最高1300Mbpsの
リンク速度で通信することができた。とはいえ最高速度で通信を行うためには厳しい条件があり、
AirMacが非常に近くにあること、またそのAirMacが物理的にiMacよりも高い場所にあることが
必要であると言えそうだ。

AirMac Extremeと2013 iMacとの組み合わせでは、レンジは全く信じがたいくらい優れたもので
あった。直近の旅行に発つ前に速度と距離の関係をプロットしている時間はなかったが、この両者の
組み合わせはこれまでテストしたどのWiFiよりもレンジとパフォーマンスに優れていたと言える。
（訳註：評価の確定には）もう少し時間を共にする必要があるが、この点においては全く感銘を受けた。

OS X 10.8.5では、Appleは802.11acの実使用上存在していた若干のパフォーマンスの問題の修正を
行った。筆者は10.8.5にアップデートする前に、iPerfを用いて素晴らしいパフォーマンスを得ることが
できたが、実使用上では、同一ネットワーク上にあるMac間でのファイルコピーの速度は802.11n上
でのそれを超えることは一度もなかった。

10.8.5アップデートではある程度この問題の対処が進み、AFPでファイル共有を行ったときのコピーの
速度を~330Mbpsまで引き上げた。現状のソフトウェアにおいて問題への対処を部分的に行うという
のは、ソフトウェア会社にとっては珍しいことではない。特に、間もなく根本的な解決策をリリースする
場合はそうだ。ここで行われていることに筆者は疑いを持っていたので、iMacとソース機（13inch MacBook Pro retina）の両方にOS X 10.9 (Mavericks)をインストールしてみた。

13inch rMBPはThunderbolt/GigE経由で接続し、iMacは同一ネットワーク上で802.11ac経由で
接続した。ではまず、iPerfを用いてUDPとTCPのパフォーマンスを見てみよう。

UDPのピーク性能は829.8Mbps。同じ条件でTCPのテストを行うと553Mbpsまで落ちる。では
実際のファイルコピー速度はどうだろうか。ピーク性能は720Mbpsまで上がったのを確認したが、
筆者のネットワーク環境では平均ファイルコピー速度は~500Mbps止まりだった。

Gigabit Ethernet経由の有線接続の方がより高い転送速度を確実に得られるが、802.11acだって
（特に距離が短い場合は）非常に良好である。802.11acの本来の性能を発揮するにはMavericks
の登場を待たなければいけないが、その時はもうすぐそこまで来ているのだ。

それ以外のIOに関しては昨年のモデルと同一だ。USB 3.0 × 4ポート、Thunderbolt 1.0 × 2ポート、
Gigabit Ethernet、SDXCカードリーダー、3.5mm音声入出力ジャックを備えている。

シャシ
Appleは昨年iMacを刷新し、エッジ部分に限ってはiPhone 5/5sやiPad miniよりも薄くなった。勿論、
エッジを薄くしても中央部分が大きく盛り上がっていては何の意味もない、と多くの人が指摘していた。
内蔵バッテリーに割くスペースが不要であることを考慮すると、十分な冷却が行われてさえいれば、
シャシの容積を減らすことは、純粋なデザイン上の冒険であった。ディスクリート型GPUを積んだ
21.5inch iMacについては分からないが、本機の65W Haswell + Crystalwellは高負荷時においても
発熱の問題は一切見られなかった。

軽負荷時、および本レビューの執筆中にCinebench R15テストを繰り返しても、iMac内蔵の唯一の
冷却ファンは~1400 RPMでわずかな風切り音を奏でるだけであった。Intelがこのマイクロプロセッサの
アーキテクチャのターゲットをノート型に定めていることの副次的な効果の一つが、この65Wの
デスクトップ用のプロセッサの冷却が楽であるという点である。筐体が非常に薄い15inchのノートと
同等のパフォーマンスを21.5inch iMacのシャシで行っていることを心に留めていただきたい。

内容積を大きく減らしてもなお、27inch iMacは持ち歩くには嵩張りすぎている。だがこれは21.5inch
iMacには当てはまらない。本体重量はわずか5.68kg（これは小型の犬や大型の猫と同じくらいである）
と軽量で、「ほぼ」ポータブルであると言える。本レビューの執筆中、筆者は様々な場所（机、写真撮影場所、WiFiのテスト中など）へ持ち歩いたが、本機がいかにコンパクトにできているかをすぐに実感
した。特に、デフォルトの状態では、一緒に運ぶ必要があるケーブルは、上手く角度のついた電源
ケーブル一本だけなのだ。

数年前に購入した24inchのCPUテスト用モニターと並べてみるのもまた面白い。この2台は解像度が
同一で、それでいてiMacの方はディスプレイの質が上なばかりか、Haswell PCまで内蔵しているの
だから。

最後に

AppleはMac史上最強のラインナップを有し続けている。来年のBroadwellは更に素敵な何かが来ること
を筆者は期待しているが、現状のHaswell Macでも昨年モデルと比較して正常進化の道を歩んでいる。

iMacのデザインは美しい。ベゼル部分の薄さに満足しているかと問われるとまだ確信は持てないが、
それ以外については、Appleが2012年に行った刷新の結果には満足している。特に21.5inchモデルでは
コンパクトさは全くもって素晴らしい。それは軽量型液晶TVのコンパクトさによく似ている。
コンパクト設計の有り難みは動かすときにのみ実感するし、たとえ滅多に動かす機会がなかったとしても
あって損はないものだ。

本レビューでは触れなかったが、内蔵のワイヤレスも良好だ。802.11ac経由でのファイル転送性能が
500Mpbsに達した（ただし近距離かつMavericks環境下だが）ことと合わせると、iMacは本当に
ケーブル1本で済むし、それでも充分満足できるものだ。新型802.11ac AirMac Extremeを使えば
ワイヤレスのレンジは更に良好だ。

iMacの液晶の質は箱出しの状態でも既に信じがたい素晴らしさだ。画像編集のプロでさえも、ふらっと
Apple Storeの実店舗に入って、21.5inchのエントリー機を買って持ち帰っただけで、素晴らしい
エクスペリエンスが得られるのだ。更なる高解像度を期待したいが、4Kのパネルはまだまだ安くない。
（27inchの5Kパネルについても言うに及ばず、だ。）

筆者はどちらも標準状態では触っていない。￥22,000のオプションのFusion DriveあるいはSSDの
おかげだ。このオプションは必須だ。Fusion Driveは触りたくなる唯一のハイブリッドソリューション
である。単一のボリュームが必要ならば、是非Fusion Driveを選ぶべきだ。

21.5inch iMacのエントリー機はCPU性能も非常に良好だ。パワーユーザー、特に高度にスレッド化
された負荷をかけるユーザーは上位機種を選びたくなるだろうが、ライトユーザーなら、この基本構成
でも充分なシングルスレッドのパフォーマンスを味わえることだろう。

21.5inch iMacのエントリー機は、グラフィック一体型チップセットとしてこれまでにない良好な
グラフィック性能を有している。OS X上でのIris Proは（ゲーム以外）良好で、ディスクリート型
グラフィックスではないことには気付かないレベルだった。

21.5inch iMacのエントリー機は発熱の問題もない。Core i5-4570RがTurbo Boost時に3.0/3.1GHz
で定常的に動作していたが、テスト中に内蔵のファンが1400RPMを上回ることはなかった。
全般的に、21.5inch iMacは非常にコンパクトで、低発熱・低騒音のコンピュータだ。21.5inch iMacは
Macのデスクトップ機を求めるすべてのユーザーに自信を持ってお薦めできる。ただし、Fusion Drive
かSSDは選んでくださいね。


おしまい。

乙です

ワッフルし続けた甲斐が有ったというものだ。
お疲れさまでした。

ars technicaの10.9解説記事から、タグの項を低品質翻訳しました。
ttp://arstechnica.com/apple/2013/10/os-x-10-9/8/

タグ
ひとめ見て、Finder ラベルが「タグ」に変わっているのが分かる。
確かに、ファインダーのメニューや環境設定では「タグ」が使われていて、「ラベル」はどこにもない。
Finderのいろんな箇所で見られたらラベルの表現方法もまた変化している。
ファイル名またはフォルダ名（または、リストビューでの一列すべて）をハイライトする代わりに、名前の後ろにカラーのドットが表示されるようになった。

画像：Finder Tags display: colored dots replace Mountain Lion's whole-row highlights.

タグに関してだけ話をすると、10年前に Panther がラベルの表示を塗りつぶしにしたことからくる見た目の混乱を遂に解決してくれた。
しばらくFinderにとどまったあと、タグがラベルとまったく同じというわけではないことを発見するだろう。
ファイルのタグを青から緑に変えようとして、例えば、UIでは何が起こっているか丁寧に説明してくれる。

画像：Multiple Tags can be applied to a single file.

ひとつの項目が複数のタブを持つとき、Finderは複数の重なったドットを、新しく加えた順に最大3つまで表示する。

画像：Multiple Tags as displayed in the Finder: the three most recent Tags are shown as dots.

注意深い観察者なら、Finderのコンテクストメニューにあるカラードットの列の上にある "Label:" テキストに気が付くだろう。
Macでは常に、「…」の付いたメニューは次の入力プロンプトにつながる。
それを選ぶと、テキスト入力フィールドにそったカラードットのリストを持つポップオーバーが現れる。
（同じ機能をFinderツールバーメニューの "タグを編集" または ファイルメニューの "タグ…" から呼び出せる。）

先へ進もう。
テキストが既に存在するタグ名に合致すると、returnキーを押すことでタグが追加され、元の入力欄に戻ると新しく追加されたタグが現れている。

画像：The Finder Tags popover: add an existing Tag by clicking on it or typing its name.

存在するタグに合致しない何かを入力してreturnすると、新しいタグが作られる。
既にファイルに付与されているタグの名前を入力すると、そのタグはタグリストの最後に移動される。

画像：The Finder Tags popover: create a new Tag or move an existing Tag.

Finder環境設定の"タグ"は、新しく作ったタグに色を割り振る方法を提供する ー 方法が直感的ではないけれど。
（答え：タグ名の左のサークルをクリック） 7色からしか選べず、色も変えることができない。
ひとつ以上のタグを同じ色に使うことができる。

画像：The devious puzzle box that is the Finder's Tags preferences.

ウインドウの下部に分かりにくいドラッグアンドドロップエリアも存在する。
上のテキストが動作を説明しようとしているが、下部にあるカラードットにラベルが欠けているので混乱を起こしている。

タグのリストを表すカラードットの横線はFinderのファイルメニューとコンテクストメニューで表示される。
タブの名前を見るには各カラードットにポインターを置く。
ドットの上のテキストがいま起きていることを述べていて、リストの一番上から一番下へドラッグすると、マウスボタンを離してドラッグを完了するまで何が起きているかを述べたテキストが表示されている。

率直に言って、ユーザーインターフェイスが壊滅状態だ。まだ各ラベルの右にあるチェックボックスの話もしていない。
これらは何をするものだと思う？ （残念、マウスオーバーしても説明は出ない）
驚きを台無しにしてあげよう。
ボックスをチェックすると、Finderのサイドバーにタグが現れるのだ；チェックを外すと現れない。

そしてまだ不思議なものが残っている。
不確定なチェックボックス（例えば、チェックマークの代わりに水平線が入っている場合）が何を指すのか想像してみよう。
（ああそうだ、マウスオーバーしても説明は出ない！） ギブアップ？ 私もギブアップしかかった。
その答えはこうだ。
10.9でどのファイルにも付与したことのないタグを最初に付与すると、それが自動的にFinderのサイドバーに現れるのだ（しかも最上位に）。
しかしユーザーがそれを求めない限りは、環境設定ウインドウにおいてチェックボックスにチェックマークが表示されない；変わりに水平線マークが表示される。
想像は当たっていたかい？ ありがたいことに、OSの運命 - あるいはFinderの - は、この環境設定ウインドウひとつで決まりはしない。
しかし安易な仕事であり、ゴチャゴチャもいいところだ。

Finderとタグの統合の残りの部分については、より洗練されている。
Finderのサイドバーでタグを選択すると、そのタグに関わる全ファイルについてのSpotlight検索が起動する。
（私の知る限り、サイドバーから複数のタグを選択する方法はない；タグがセットされているものすべてを検索するにはSpotlightを使う） サイドバーでタグをドラッグすると並べ替えができる。
Finderのサイドバーでタグを選択しておいて、そのウインドウにファイルをドラッグするとそのタグが付与される（検索が更新されてウインドウに表示される）。
通常は、同じサイドバーが開く・保存ダイアログに現れる。
標準の保存ダイアログはタグを入力または変更する新しいフィールドを備えている。
便利ではあるが、人によっては混乱するだろう。フィールドが空のときは、すぐ上にあるファイル名フィールドと見た目がそっくりだ。

画像：Add tags when saving a document―just make sure you enter them in the correct field.

このそっくりなテキストフィールドのせいで、ファイルを保存するときに何度かギョッとしたことがある。
初心者がタグフィールドにファイル名を入力してしまい、続いて出るエラーメッセージを理解できないという光景が容易に想像される。
Lionで導入された書類バージョン用のタイトルバーポップアップメニューでもタグを編集できる。

画像：Move over, versions. Tags now get pride of place in the title bar pop-up menu.

旧式の "移動…" コマンドは、iCloudフォルダ、お気に入り、装置、最近の場所、そして一番下に "その他…" を含むポップアップメニューに置き換えられた。
書類バージョンの機能はタイトルバーポップアップメニューからのほか、ファイルメニューの "バージョンを戻す…" からもアクセスできる。

ここからは、ttp://arstechnica.com/apple/2013/10/os-x-10-9/9/ の翻訳です。


タグの実装

OS Xにおけるファイルシステム・メタデータは恐ろしく凸凹な道を辿っている。
哲学面と技術面の両方の理由により、NeXTからの派生物はClassic Mac OSの遺産であるメタデータを歓迎しなかった。
代替案は、なし。

いまや、そんな決定は古代の歴史だ。
動物の名前のごとく、ファイル名にファイルタイプ情報を挿入する習慣から抜け出せていないが、最後には、ファイルシステムメタデータは10.4で予見された通りに降臨する。

Mac OS X 10.4 での転換点は、arbitrarily extensible file system metadataのサポートを追加したことだ。
ファイル名だけでなく、いくつかの日付、アクセス権や所有権などもある。
現在は、arbitrary nameと値のセットを加えることでファイルにいろいろな情報を付与することができる。

access control listsやTime Machineのような目玉機能のローレベル実装に使われているこの機能の、初めてにして最大の受益者はOS X自身だ。
Mavericksでも、タグの機能は同じメカニズムだろうと予測するのが普通だ。
思った通り、そうだった - 予想とは異なるやり方で。
そこに取りかかる前に、どのようにしてレガシーなラベルメタデータが保管されているかを考えてみよう。

ラベル

ラベルの登場は、1988年のSystem6まで遡る。
AppleがFinderとファイルシステムの両方を創ったときから、Finder Infoと呼ばれるファイルシステムメタデータにラベルが保管されていた。
この構造体はFinderに役立つ情報を含んでいて（たいていはbit fields に格納されていた - おいおい、1988年だぞ）、ラベルカラーは3bitで保管されていた。

もし1988年のファイルシステムの細部が今日のMacを志向していたとしたら素敵なことだろう。
悲しいかな、OS XはFinderラベルが創られたときと大体同じファイルシステムを使い続けている。
Finder Info構造体はファイルシステム内で相変わらず古い場所と形式を保っている。

現代に目をやると、OS XにおいてFinder Infoは com.apple.FinderInfo と名付けられた "偽物の" 拡張attributeを通して開示されている。
HFS+ボリュームの拡張attributeを読み書きするコードは、attribute名がcom.apple.FinderInfoかどうかを確認して、そうであればファイルシステムから実際のHFS+ Finder Infoレコードを読み出す別のコードに処理を分岐する。
（リソースフォークは、attribute名がcom.apple.ResourceForkのときに似たような方法を通して開示される。）

つまるところ、xattrコマンドでFinder Infoを見ることができる。この例では、"赤色" ラベルがファイル名Helloに付与されている。

% xattr -p com.apple.FinderInfo Hello
00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00
その 0C ビットパターンが赤色ラベルを表す。
Finder Info内ではラベルカラー用にたった3bitしか割り当てられておらず、すなわち最大7色が限界だった（001から111まで。000はラベルなしを表す）。
赤色は色番号 6: 0x0C はバイナリで 1100 となるが、最後のビットはラベルのビットフィールドではない。
残りは 110 で、10進法で表すと「6」だ。

タグ

カラーに割り当てられたタグがファイルに付与されるとき、上記で述べた形でラベル情報はFinder Infoに書き込まれ、タグはMavericks以前のシステムと互換性を一部保つ形にされる。
色の付いたタグがさらにファイルに付与されると、ラベル情報は最も新しく付与されたタグを反映する。
もしタグに色が割り当てられていないときは、ラベル情報は変更されない。

実際のタグ情報は個別に分離された拡張attribute、com.apple.metadata:_kMDItemUserTagsに保管される。
（私の知る限り、これは "普通の" 拡張attributeであり、com.apple.FinderInfo や com.apple.ResourceFork のようなレガシーHFS+メタデータの代理品ではない） この例では、"緑色" と "赤色" ラベルがファイル名Helloに順番に付与されている。

% xattr -l Hello
com.apple.FinderInfo:
00000000 00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
com.apple.metadata:_kMDItemUserTags:
00000000 62 70 6C 69 73 74 30 30 A2 01 02 57 47 72 65 65 |bplist00...WGree|
00000010 6E 0A 32 55 52 65 64 0A 36 08 0B 13 00 00 00 00 |n.2URed.6.......|
00000020 00 00 01 01 00 00 00 00 00 00 00 03 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 19 |............|
0000003c
予想された 0C ビットパターンが Finder Infoにあり、これは最後のタグに割り当てられた "赤色" だ。
タグのメタデータASCIIダンプは、バイナリ形式の property listにおける秘密のbplist列から始まっている。
バイナリ形式のproperty listを理解できるhexエディタとテキストエディタの助けを借りて、タグのメタデータの内容を明らかにしよう：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<string>Green
2</string>
<string>Red
6</string>
</array>
</plist>
二つのタグ名、GreenとRedが追加順に並んでいて、10進法のラベルカラー値（緑色は2、赤色は6）が添えられている。

property list内のタグ情報の形式は実に奇妙だ。
あなたが見ているのは幻ではない；10進法のラベルカラー値とタグ名とが、Unixの改行キャラクタ (0x0A) によって分割されている。
なぜ<string>と<integer>に分離して保管するかわりに単一のstrings値に納めたのか、私には想像もつかない。
(ファイル拡張子での出来事を気にしたのだろうか？）

カラーが加えられていないタグはただ文字列だけで、改行コードもラベルカラー値も存在しなくなる：
...
<array>
<string>Green
2</string>
<string>Red
6</string>
<string>Essential</string>
</array>
...
タグごとにひとつの拡張attributeを使うのではなく、単一の拡張attributeにタグ情報が格納されているのを発見したときは最初驚いたが、Spotlightの検索とインデックス作成がどういう仕組みかを考えるとなるほどと思える。
mdlsコマンドはタグ情報を以下のキーで表示する：

% mdls -name kMDItemUserTags Hello
kMDItemUserTags = (
Green,
Red,
Essential
)
タグのラベルカラー値はSpotlightのメタデータには渡されない；タグ名だけが保管される。

レガシーなラベル情報はMountain Lionまではずっと同じで、カラー値だけがSpotlightに渡されていた：

% mdls -name kMDItemFSLabel Hello
kMDItemFSLabel = 6
この実装詳細は深遠であり些細な事柄でもあるように見えるが、ユーザー体験の大元に影響がある。
レガシーなラベルシステムから来る、変化のない7種類の整数カラー値。つまり後方互換性が与えられているわけで、なぜタグが7色しか色を使えずその色も変えられないのかの理由もそれだ。

タグの値にplain strings（ただの文字列）を使うのは、共有ファイルにおいて正確に表示するために必要だからだ；すべてのMacがタグ名を読み込んで表示させられるように。
しかしそれぞれのタグ名に結びついた色は、システムごとにバラバラだ。
もし複数のユーザーが "Hot" という名前のタグを作り、しかし違う色を選択すると、ファイルに付与されるタグのメタデータに書き込まれる整数カラー値も異なるものになる。
"Hot" ラベルの付いたファイルを見るときは、ファイルに付与されたタグメタデータに保管された色ではなく、ユーザーが "Hot" タグにあてがっている色を見るだろう。

各ファイルのメタデータにタグ名と色を保管することはつまり、タグの色を変更すると、そのタグを持つすべてのファイルの整数カラー値を更新する必要が生じるということになる。
もちろん、これは現ユーザーが変更権限を持つファイルに対してだけ行なわれる。
時間のかかる作業になる可能性もある；Maverickではタグの色を変更中にプログレスバーが表示されることがある。
タグの名前変更も同じ作業であり、注意ダイアログも同じものだ。

このシステムには二律背反するところが数多くある。
タグのメタデータが、Finderやそれ以外で表示される色と常に一致しているわけではない。
タグ名と色の変更がタグを使っているすべてのファイルに伝播することはないだろう。
ファイルに付与されたタグの順番により、Mavericks以前のシステム上で見えるラベルカラーが決定される。

これらのどっち付かずな状況が通常の使用状態ではまれであることを期待しよう。
いくつかの作業では、タグのデータ保管実装は正規化に少しは寄与する。
例えば、タグ名とカラーが、「各ファイルのメタデータ」という単一の場所に保管されている場合、タグ名とカラーの更新は線形関数ではなく定数時間で済ますことができる。
不幸なことに、共有ファイルについての、タグのメタデータ保護および表示はもっとずっと難しい - いくつかの場面では不可能になる。

後方互換性を支持し、パフォーマンスとストレージ効率が最悪になる場面があることを押し切った、不完全なシステムをAppleは選んだ。
最後に、私はそれについてAppleを非難することはできない。
しかしTigerにおけるUTIの問題や実装効率といった、横たわる茨の路にAppleが果敢に取り組むところも見てみたいと思うのだ。

すばらしく乙
後でじっくり読むよ

もしよければ、他の所も読んでみたいなー

ars technicaの訳、定期的に上がるけど同じ人かな？乙です

ars technicaのMavericksレビュー（byシラクサ氏）から、Sprite Kitの項目を訳してみました。

Sprite Kit

http://arstechnica.com/apple/2013/10/os-x-10-9/21/#sprite-kit

去年、アップルは Scene Kit というフレームワークを導入した。いわば3D版Core Animationである。これ
らのおかげで、以前ならOpenGLとかGPUアクセラレーションを使ったコーディングと聞いただけで声上げ
て逃げ出してたようなプログラマーにとっても、グラフィック関連の開発が取っ付きやすいものになった。

Scene Kit、私自身はずいぶん興奮させられたんであるが、まだ登場からわずか1年ということもあって、
Mac開発者コミュニティ全体に火をつけるまでには至っていないようだ。知る限りでは、Scene Kitを活用し
た著名なMacアプリはDelicious Library 3だけだ。

http://cdn.arstechnica.net/wp-content/uploads/2013/10/[email protected]
（Delicious Library 3は仮想の棚に並んだ書籍や映画作品を3Dで描いている。ハイライトさえも3Dだ)

バーチャル棚の上のブツにちょっとした重量感を与えたりキラッとさせたりするために3Dを活用するのは、
実に控えめでイイ感じな使い方だと私は思うのだが、全く逆の感想を耳にしたこともある。たぶん、3Dモデ
ルによる描画は2Dよりも好みが分かれやすいのだろう。

Scene Kitは3Dゲーム開発に使えないこともないが、本来の目的はゲームではなく、通常のMacアプリケーシ
ョンで3Dモデルや3D効果を使いやすくするためだ。3Dをアプリに活用すること自体がそもそも良いことな
のか悪いことなのか、議論はあるだろうが、そこはともかくとして、少なくともScene Kitが所期の目的を果
たしているとは言えるだろう。Delicious Library 3はその好例だ。

（つづく）

（つづき）

Mavericksには、Sprite Kitというフレームワークが含まれている。これは明らかにScene Kitと同系統であ
る。Appleでどちらの開発が先に始まったのかは分からないが、これらのフレームワークのクラスに付けられ
た名称を見ると、あることに気づく。Sprite Kitはクラスの接頭辞が“SK”であるのに対し、Scene Kitのクラス
は“SCN”なのだ。

スプライトというのは、背景領域の中を自在に移動させ、操ることができる独立した2D画像のことである。
初代ファミコンのゲームをやったことがあるなら、そこで見たはずだ。画面中を動き回るプレイヤーキャラ
やアイテム、そして敵は全てスプライトである。

お分かりだろう。Sprite KitはMacアプリケーションでこのような2Dスプライトを使いやすくするためのもの
だ。おいちょっと待て、それってCore Animationがもうカバーしているんじゃないか、という声もあるだろ
う。しかし違うのだ。Core AnimationとScene Kitは普通のアプリが対象だが、Sprite Kitはゲームのためだ
けに設計されたフレームワークなのである。

ゲームでは、普通のアプリケーションとは全然違うことが要求される。アプリでアニメーションが使われる
のは何かの表示切替えの時だけだが、ゲームは絶えずアニメーションしている。一画面内で同時に動きまわ
る要素の数もずっと多いだろう。それに、ただスライドして出てきたりフェードイン・アウトしたりするだ
けのシートやダイアログボックスとは違って、ゲーム内で動く要素は相互に作用を及ぼし合わないといけな
い。

（つづく）

（つづき）

Sprite Kitは2Dゲーム開発のために必要な道具一式を提供する。スプライト同士の相互作用を処理するための、
衝突判定機能つき物理エンジン。自在な拡大・縮小・変形機能。Core Imageフィルターやパーティクル効果の適
用。

一人称視点のゲームシステムに使える隠面処理機能、それにベクター図形やテキストをゲーム画面に表示できる
機能もある。なんとビデオ映像をスプライトにしちゃえたりもする。しかも普通のスプライトと同じくあらゆる
表示効果や変形、物理効果を適用できる。そして、全ての機能はObjective-CのAPIから呼び出すことができるの
だ。これは、よくあるゲームエンジンのための低レベルな（＝マシン語に近い）C/C++コードよりも、段違いに
使いやすく抽象化されたものだ。

しかし、コードを書く作業はゲーム開発のほんの一部にすぎない。これをよく分かっているアップルは、さらに
一歩進んで、統合開発環境XcodeにSprite Kit専用の機能を追加した。Xcodeは、複数の画像ファイルを自動的に
組み合わせて、巨大で効率がいいテクスチャー集合体（Texture Atlas）を作ることができる。また、パーティク
ル効果エディターも統合されている。パーティクル効果の作成や調整といえば、これまではパラメーターを一々
いじっては再コンパイルして、という煩わしい作業だったのだが、それが視覚的な楽しい経験に変わる。

http://cdn.arstechnica.net/wp-content/uploads/2013/10/[email protected]
（リアルタイムな視覚的インターフェイスを使って、Xcodeの中でSprite Kitのパーティクル効果を作成・編集す
ることができる）

最後に念のため付け加えておくが、Sprite KitはOS XでもiOSでも使うことができる。ここまで大規模でありなが
ら2Dゲーム制作にしか使えない、しかもMacのためだけのフレームワークを開発するとか、ありえません。さす
がのアップルもそこまでアホではない。

（つづく）

（つづき）

古参のゲーム開発者だったら、こういう「あなただけの2Dゲーム作れます」的な、Appleお仕着せのツールキッ
トなど鼻で笑うかもしれない。すでに自前のスプライトエンジンくらいCやC++で書いてあるだろうし、マルチ
プラットフォームでの大規模なゲーム開発の一環として素材の作成・供給ラインを独自に組んでいるだろうから
だ。

しかし何と言っても、iOSで凄いゲームが作りたい小さな開発チームにとっては、Sprite Kitは強力な後押しにな
るだろう。しかも、もし注意深くコーディングすれば、同じゲームのMac版をほとんど追加作業なしに作れると
いうボーナスまでついてくるのだ。

そして、古株開発者にもぜひ言いたい。もしアップルの開発者アカウントを持っているなら、だまされたと思っ
てWWDCのセッション502、「Sprite Kit導入編」を見てみてほしい。Mac・iOSのためにスプライトを使って高
品質なゲームを作るのがどれだけ楽になったか、絶対に感銘を受けるから。「見たけど何とも思わなかった」な
んて言えるもんなら言ってみろって、マジで。

私にとって、去年のWWDC最大のサプライズはScene Kitだった。こんなに楽しくて凄いフレームワークが発表
されるなんて誰も想像してなかったのだから。Sprite Kitはそれよりも予想のつきやすいものではあったが、同じ
くらい大したものだ。Scene Kitよりも広く活用されたらいいと思う。

（おわり）

ヤバい、Sprite Kitヤバい。ヤバいのでageます。

Sprite Kitの訳、実は２箇所自信がありません。

１．"There’s a ray casting system for game mechanics based on line-of-sight"
→「一人称視点のゲームシステムに使える隠面処理機能」

・・・とやりましたが、"based on line-of-sight"ってこういうことでいいんだろうか。誰か3Dゲーム
プログラマの人いませんか。

２．"Not even Apple is foolish enough to create a framework this extensive for the sole purpose
of creating 2D games for the Mac."
→「ここまで大規模でありながら2Dゲーム制作にしか使えない、しかもMacのためだけのフレームワー
クを開発するとか、ありえません。さすがのアップルもそこまでアホではない。」

・・・「いかにfoolishなアップルとはいえ、そこまでfoolishではない」ということなんですが、シラク
サ氏が「アップルはfookish」という前提を置いたのは何が理由なんだろうか。

他にも問題があったら突っ込んで下さいな。

2はジョブズの"Stay hungry, stay foolish."に掛けているのかな？

>>822
そ　　れ　　だ　　！

>>821
乙です。
Sprite Kitってそういうものだったのか…

ちょっと公式ドキュメントに当たってみたら
ray casting についてはこちらに記述がありました。
https://developer.apple.com/LIBRARY/IOS/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/Physics/Physics.html#//apple_ref/doc/uid/TP40013043-CH6-SW32

2Dのフレームワークなので隠面処理とかの話ではありませんね。
「敵は自キャラを発見すると攻撃開始する」みたいな処理をしたいときに
敵と自キャラの間に遮蔽物があるか判定するような用途が想定されています。

元記事の文脈だと訳しにくいですが
「ゲームメカニズムに視線を組み込むためのレイキャスティングシステム」
くらいが妥当でしょうか。
「レイキャスティング」は日本語に訳されてるのを見たことないので
そのままでいいでしょう。

ただし原文の表現もちょっと不正確で、
レイキャスティングは衝突判定の一種であって
視線専門システムでないことは訳注しておきたいところです。
（発射した銃弾が何に当たったか、みたいな処理にも使える）