Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7
>>395
一番面白そうなところを翻訳しました。しかし分量が多すぎる。
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3
インストール
Apple によると、Snow Leopardのインストールは「最大45%」高速になったそうだ。
インストール時間は、速度、内容物、ディスクの断片化の程度、光学ドライブの速度などによって大きく変わる。
インストールというのは一度きりで、恐ろしい事態が起きない限りは特に面白くもない。
ま、Appleがそういうなら、確認する価値がある。
条件をできるだけ同じにするべく、私はLeopardとSnow Leopardの両方をインストールした。
光学ドライブからのランダムなデータアクセスを抑えるため、Snow Leopardの最も重要なインストール最適化のいくつかを無効にしている。
不利な条件にも関わらず、Snow LeopardのインストールはLeopardのそれよりも20%ほど短い時間ですんだ。
Appleのいう「最大45%」には届かなかった（最大、という枕詞を忘れずに）。どちらも、インストールは30分以下だった。
Snow Leopardで驚くのは、Spotlightのインデックス作成が非常に速く完了することだ。
私のテストでは、Snow Leopardは174%も高速だった。5:49 に対して 3:20。
さらに、空のディスクへの新規インストールは標準ではない。
しかし、Spotlightのインデックス作成の待ち時間が短くなったのはいい。
Snow Leopardのパフォーマンスを実感できる最初の体験だ。
一番面白そうなところを翻訳しました。しかし分量が多すぎる。
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3
インストール
Apple によると、Snow Leopardのインストールは「最大45%」高速になったそうだ。
インストール時間は、速度、内容物、ディスクの断片化の程度、光学ドライブの速度などによって大きく変わる。
インストールというのは一度きりで、恐ろしい事態が起きない限りは特に面白くもない。
ま、Appleがそういうなら、確認する価値がある。
条件をできるだけ同じにするべく、私はLeopardとSnow Leopardの両方をインストールした。
光学ドライブからのランダムなデータアクセスを抑えるため、Snow Leopardの最も重要なインストール最適化のいくつかを無効にしている。
不利な条件にも関わらず、Snow LeopardのインストールはLeopardのそれよりも20%ほど短い時間ですんだ。
Appleのいう「最大45%」には届かなかった（最大、という枕詞を忘れずに）。どちらも、インストールは30分以下だった。
Snow Leopardで驚くのは、Spotlightのインデックス作成が非常に速く完了することだ。
私のテストでは、Snow Leopardは174%も高速だった。5:49 に対して 3:20。
さらに、空のディスクへの新規インストールは標準ではない。
しかし、Spotlightのインデックス作成の待ち時間が短くなったのはいい。
Snow Leopardのパフォーマンスを実感できる最初の体験だ。
|
|
|
ほかに特筆すべき点として、デフォルトではインストールされないものについてだ。
例えばRosettaは、IntelMacでPowerPCのバイナリを動作可能にする。
オーケーわかった、 PowerPCはもう死んだ。安らかに眠れ。カーテンを引いて天に召されよ。
Appleに限っていえば、PowerPCは蚊帳の外だ。
しかし、デフォルトでRosettaをインストールしない？ キツい表現をするとこれは無謀と言える。
Snow Leopardにアップグレードした後に、長い間放置していたPowerPCアプリケーションを起動したらどうなるだろうか？
驚くと思うが、こうなる：
（スクリーンショット）
Rosetta：自動インストールされる
Disk Inventory X を Snow Leopardで起動しようとした時にこれが現れた。
PowerPCアプリケーションだというのを忘れていたのだ。
「インストール」ボタンをクリックした後、インストールDVDを要求されるだろうと思っていた。
代わりに、Snow Leopardはネットワークに接続し、AppleのサーバからRosettaをダウンロードしてインストールしたのだ。
（スクリーンショット）
Rosetta 自動インストール
Macの再起動も要求されず、 Disk Inventory X はRosettaのインストール完了後にそのまま起動した。
Mac OS X は今までシステムソフトウァアのオンデマンドインストールをあまり使ってこなかったが、Rosettaに関する便宜はとても好ましい。
「インストール」をクリックすると、Mac OS Xに適用可能なソフトを列記した巨大なXMLプロパティリストがダウンロードされる。
Snow Leopard は同様にプリンタードライバもオンデマンドでダウンロード・インストールしてくれる。
インストールDVDを持ち出す手間が省ける。将来はこの技術がもっと広く使われるとありがたい。
例えばRosettaは、IntelMacでPowerPCのバイナリを動作可能にする。
オーケーわかった、 PowerPCはもう死んだ。安らかに眠れ。カーテンを引いて天に召されよ。
Appleに限っていえば、PowerPCは蚊帳の外だ。
しかし、デフォルトでRosettaをインストールしない？ キツい表現をするとこれは無謀と言える。
Snow Leopardにアップグレードした後に、長い間放置していたPowerPCアプリケーションを起動したらどうなるだろうか？
驚くと思うが、こうなる：
（スクリーンショット）
Rosetta：自動インストールされる
Disk Inventory X を Snow Leopardで起動しようとした時にこれが現れた。
PowerPCアプリケーションだというのを忘れていたのだ。
「インストール」ボタンをクリックした後、インストールDVDを要求されるだろうと思っていた。
代わりに、Snow Leopardはネットワークに接続し、AppleのサーバからRosettaをダウンロードしてインストールしたのだ。
（スクリーンショット）
Rosetta 自動インストール
Macの再起動も要求されず、 Disk Inventory X はRosettaのインストール完了後にそのまま起動した。
Mac OS X は今までシステムソフトウァアのオンデマンドインストールをあまり使ってこなかったが、Rosettaに関する便宜はとても好ましい。
「インストール」をクリックすると、Mac OS Xに適用可能なソフトを列記した巨大なXMLプロパティリストがダウンロードされる。
Snow Leopard は同様にプリンタードライバもオンデマンドでダウンロード・インストールしてくれる。
インストールDVDを持ち出す手間が省ける。将来はこの技術がもっと広く使われるとありがたい。
インストールのサイズ
Snow Leopardはディスクを節約する。
Appleは「前のバージョンよりもサイズを半分近く減らした」と言っているが、これは嘘ではない。
クリーンなデフォルトインストール（Spotlightのインデックスも含む）でいうと、Leopardが16.8GBで、Snow Leopardは5.9GBだ。
（ちなみに、この数字はどちらも2進法で計っている。サイドバーをみてね）
ギガバイトの、ほかの名前
Snow Leopard は、ディスクの使用率について上げ底的なトリックを使っている。
Snow LeopardのFinderは1GBを109バイト（10億）としているが、
LeopardのFinder、いや、従来のすべてのFinderは1GBを230バイト（10億7374万1824）としているのだ。
Snow Leopardをインストールした後は、ディスクの容量が突然増えたように見える。
たとえば、私の1TBのハードディスクをLeopardのFinderでみると、931.19 GBと表示される。
Snow Leopardでは、999.86 GBだ。ハードディクのメーカーは、10進法を使っている。
まったく混乱させてくれる。
私は2進法に拘っているとしても、長らく定着していたハードディスクメーカーの表記ルールにAppleが合わせたことを強く非難はできない。
Snow Leopard の減量にはいくつか秘密がある。
ひとつは明らかだ：PowerPCのサポートが無くなったということは、PowerPCの実行コードも無いということ。
Leopard で実行コードをフルに載むと？ 32ビットPowerPC、64ビットPowerPC、 x86、そしてx86_64。
これらアーキテクチャの半分がカットされた。
とはいえ、Leopardでは64ビットのコードを持つアプリケーションはほとんどなかったが。
しかし50%の実行コードの削減は単純に効く。
Snow Leopardはディスクを節約する。
Appleは「前のバージョンよりもサイズを半分近く減らした」と言っているが、これは嘘ではない。
クリーンなデフォルトインストール（Spotlightのインデックスも含む）でいうと、Leopardが16.8GBで、Snow Leopardは5.9GBだ。
（ちなみに、この数字はどちらも2進法で計っている。サイドバーをみてね）
ギガバイトの、ほかの名前
Snow Leopard は、ディスクの使用率について上げ底的なトリックを使っている。
Snow LeopardのFinderは1GBを109バイト（10億）としているが、
LeopardのFinder、いや、従来のすべてのFinderは1GBを230バイト（10億7374万1824）としているのだ。
Snow Leopardをインストールした後は、ディスクの容量が突然増えたように見える。
たとえば、私の1TBのハードディスクをLeopardのFinderでみると、931.19 GBと表示される。
Snow Leopardでは、999.86 GBだ。ハードディクのメーカーは、10進法を使っている。
まったく混乱させてくれる。
私は2進法に拘っているとしても、長らく定着していたハードディスクメーカーの表記ルールにAppleが合わせたことを強く非難はできない。
Snow Leopard の減量にはいくつか秘密がある。
ひとつは明らかだ：PowerPCのサポートが無くなったということは、PowerPCの実行コードも無いということ。
Leopard で実行コードをフルに載むと？ 32ビットPowerPC、64ビットPowerPC、 x86、そしてx86_64。
これらアーキテクチャの半分がカットされた。
とはいえ、Leopardでは64ビットのコードを持つアプリケーションはほとんどなかったが。
しかし50%の実行コードの削減は単純に効く。
もちろん、OSの全ファイルが実行コードという訳ではない。
データファイル、イメージ、オーディオ、ビデオ。
しかし実行コードでないファイルのほとんどに共通することがある：それらはたいてい、圧縮されたファイルフォーマットで保管されている。
PNGs、JPEG、AAC、MPEG-4、そして設定ファイルやプロパティリストは、XMLよりもコンパクトなバイナリ形式がデフォルトになった。
Snow Leopardの圧縮分野では、これらとは別種のファイルが頭角を現している。
ひとつ例を見せよう。Snow Leopardでは、内在する実行ファイルのうち97%が圧縮されているのだ。
どうやって？ これを見てくれ：
% cd Applications/Mail.app/Contents/MacOS
% ls -l Mail
-rwxr-xr-x@ 1 root wheel 0 Jun 18 19:35 Mail
（訳者注：ファイルサイズが0KBとなっている）
え？ ちょ、おま…小さいってレベルじゃねーぞ？ マジで実行ファイルか？ 別の何かか？ 確認しよう。
% file Applications/Mail.app/Contents/MacOS/Mail
Applications/Mail.app/Contents/MacOS/Mail: empty
（訳者注：empty表示に注目）
キター！ 消えてるwww
種明かしをすると、この結果はLeopardからSnow Leopardのディスクを見た時のものだ。
実際、以前のMac OS Xからでは、Snow Leopardで圧縮されているファイルは0バイトに見えてしまう。
（もちろん、Snow Leopardで起動していると、ちゃんと見える）
データファイル、イメージ、オーディオ、ビデオ。
しかし実行コードでないファイルのほとんどに共通することがある：それらはたいてい、圧縮されたファイルフォーマットで保管されている。
PNGs、JPEG、AAC、MPEG-4、そして設定ファイルやプロパティリストは、XMLよりもコンパクトなバイナリ形式がデフォルトになった。
Snow Leopardの圧縮分野では、これらとは別種のファイルが頭角を現している。
ひとつ例を見せよう。Snow Leopardでは、内在する実行ファイルのうち97%が圧縮されているのだ。
どうやって？ これを見てくれ：
% cd Applications/Mail.app/Contents/MacOS
% ls -l Mail
-rwxr-xr-x@ 1 root wheel 0 Jun 18 19:35 Mail
（訳者注：ファイルサイズが0KBとなっている）
え？ ちょ、おま…小さいってレベルじゃねーぞ？ マジで実行ファイルか？ 別の何かか？ 確認しよう。
% file Applications/Mail.app/Contents/MacOS/Mail
Applications/Mail.app/Contents/MacOS/Mail: empty
（訳者注：empty表示に注目）
キター！ 消えてるwww
種明かしをすると、この結果はLeopardからSnow Leopardのディスクを見た時のものだ。
実際、以前のMac OS Xからでは、Snow Leopardで圧縮されているファイルは0バイトに見えてしまう。
（もちろん、Snow Leopardで起動していると、ちゃんと見える）
じゃ、データはどこに？
上記の出力にある、アクセス権を表す文字列の末尾についた「@」（Leopardで登場した機能）がヒントだ。
Mailの実行ファイルはサイズ0だが、それはいくつかの拡張アトリビュートを持っている：
% xattr -l Applications/Mail.app/Contents/MacOS/Mail
com.apple.ResourceFork:
0000 00 00 01 00 00 2C F5 F2 00 2C F4 F2 00 00 00 32 .....,...,.....2
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
(184,159 lines snipped)
2CF610 63 6D 70 66 00 00 00 0A 00 01 FF FF 00 00 00 00 cmpf............
2CF620 00 00 00 00 ....
com.apple.decmpfs:
0000 66 70 6D 63 04 00 00 00 A0 82 72 00 00 00 00 00 fpmc......r.....
ふぅ、これが全データだ。でも待てよ、リソースフォークに格納されてるの？
8年ほど前、それは推奨しないってことにしたよね？
確かにそう。あなたは、Appleが愛する自慢のファイルシステム、HFS+の追加機能の目撃者になる。
Mac OS Xのあけぼのに、Appleはジャーナリング、シンボリックリンク、ハードリンクを追加した。
Tigerでは、拡張アトリビュートとAccess Control Listを組み込んだ。
Leopardでは、HFS+ はディレクトリのハードリンクをサポートした。
Snow Leopardでは、HFS+ は新しい技を覚えた：per-file compression（ファイル単位の圧縮）。
com.apple.decmpfs アトリビュートの存在が、そのファイルが圧縮されているという最初のヒント。
このアトリビュートは、実際にはSnow Leopardが起動した時にxattrコマンドから見えないようにされる。
しかし、この特別なアトリビュートを解釈しないLeopardからは、丸見えだ。
上記の出力にある、アクセス権を表す文字列の末尾についた「@」（Leopardで登場した機能）がヒントだ。
Mailの実行ファイルはサイズ0だが、それはいくつかの拡張アトリビュートを持っている：
% xattr -l Applications/Mail.app/Contents/MacOS/Mail
com.apple.ResourceFork:
0000 00 00 01 00 00 2C F5 F2 00 2C F4 F2 00 00 00 32 .....,...,.....2
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
(184,159 lines snipped)
2CF610 63 6D 70 66 00 00 00 0A 00 01 FF FF 00 00 00 00 cmpf............
2CF620 00 00 00 00 ....
com.apple.decmpfs:
0000 66 70 6D 63 04 00 00 00 A0 82 72 00 00 00 00 00 fpmc......r.....
ふぅ、これが全データだ。でも待てよ、リソースフォークに格納されてるの？
8年ほど前、それは推奨しないってことにしたよね？
確かにそう。あなたは、Appleが愛する自慢のファイルシステム、HFS+の追加機能の目撃者になる。
Mac OS Xのあけぼのに、Appleはジャーナリング、シンボリックリンク、ハードリンクを追加した。
Tigerでは、拡張アトリビュートとAccess Control Listを組み込んだ。
Leopardでは、HFS+ はディレクトリのハードリンクをサポートした。
Snow Leopardでは、HFS+ は新しい技を覚えた：per-file compression（ファイル単位の圧縮）。
com.apple.decmpfs アトリビュートの存在が、そのファイルが圧縮されているという最初のヒント。
このアトリビュートは、実際にはSnow Leopardが起動した時にxattrコマンドから見えないようにされる。
しかし、この特別なアトリビュートを解釈しないLeopardからは、丸見えだ。
Mac OS X 内部をよく知る導師、Amit Singh による hfsdebug。
これのSnow Leopard対応版を使えばより多くの情報が明らかになる。
% hfsdebug /Applications/Mail.app/Contents/MacOS/Mail
...
compression magic = cmpf
compression type = 4 (resource fork has compressed data)
uncompressed size = 7500336 bytes
見ての通り、リソースフォークは確かに圧縮データを保持している。
しかし、なぜリソースフォークなのか？ Appleのいつもの、後方互換性のための賢いやり方だ。
最近の例としては、ディレクトリのハードリンクの見せ方が挙がる。
Leopard以前のバージョンでは、エイリアスに見えるようになっているやつ。
HFS+ の圧縮は過去のシステムには存在していないため、
Snow Leopard以前のシステムでは圧縮データの読み出しや解釈ができないようにしてある。
10.6以前のシステムで稼働しているアプリケーション（またはユーザ）が、圧縮されたファイルを不用意に弄ってしまわないよう、圧縮データを見えないようにしたのだ。
そのような方法で隠されている、もしかすると巨大なファイルを、Snow Leopard以前のシステムは正しくコピーできるのだろうか？
これこそ、リソースフォークを使う理由だ。
ファイルを移動したりコピーしたりする際、FinderはMac固有のメタデータとリソースフォークを正しく扱ってくれる。
Leopardでは、cpとrsyncも同じ動作をしてくれる。
以前のOSからSnow Leopardのディスクを見ると、空っぽで0KBのへんてこなファイルに見えるが、コピーや移動を行ってもデータを失う可能性は低い。
これのSnow Leopard対応版を使えばより多くの情報が明らかになる。
% hfsdebug /Applications/Mail.app/Contents/MacOS/Mail
...
compression magic = cmpf
compression type = 4 (resource fork has compressed data)
uncompressed size = 7500336 bytes
見ての通り、リソースフォークは確かに圧縮データを保持している。
しかし、なぜリソースフォークなのか？ Appleのいつもの、後方互換性のための賢いやり方だ。
最近の例としては、ディレクトリのハードリンクの見せ方が挙がる。
Leopard以前のバージョンでは、エイリアスに見えるようになっているやつ。
HFS+ の圧縮は過去のシステムには存在していないため、
Snow Leopard以前のシステムでは圧縮データの読み出しや解釈ができないようにしてある。
10.6以前のシステムで稼働しているアプリケーション（またはユーザ）が、圧縮されたファイルを不用意に弄ってしまわないよう、圧縮データを見えないようにしたのだ。
そのような方法で隠されている、もしかすると巨大なファイルを、Snow Leopard以前のシステムは正しくコピーできるのだろうか？
これこそ、リソースフォークを使う理由だ。
ファイルを移動したりコピーしたりする際、FinderはMac固有のメタデータとリソースフォークを正しく扱ってくれる。
Leopardでは、cpとrsyncも同じ動作をしてくれる。
以前のOSからSnow Leopardのディスクを見ると、空っぽで0KBのへんてこなファイルに見えるが、コピーや移動を行ってもデータを失う可能性は低い。
Appleが圧縮データをこっそり運ぶと決めた場所は、リソースフォークだけではない。
より小さなファイルについて、hfsdebugを使うと：
% hfsdebug /etc/asl.conf
...
compression magic = cmpf
compression type = 3 (xattr has compressed data)
uncompressed size = 860 bytes
この例では、（圧縮してはいるが）拡張アトリビュートにすっぽり格納できるほどデータが小さい。
そして、これが最後のフロンティア：
% hfsdebug /Volumes/Snow Time/Applications/Mail.app/Contents/PkgInfo
...
compression magic = cmpf
compression type = 3 (xattr has inline data)
uncompressed size = 8 bytes
うんうん、拡張アトリビュートに非圧縮なファイルがまるごと格納されているね。
ここで見ているような標準的なPkgInfoファイルは、Classic Mac OS由来のタイプコードとクリエイターコード（各4バイト）を保持しているだけだ。
% xattr -l Applications/Mail.app/Contents/PkgInfo
com.apple.decmpfs:
0000 66 70 6D 63 03 00 00 00 08 00 00 00 00 00 00 00 fpmc............
0010 FF 41 50 50 4C 65 6D 61 6C .APPLemal
「fpmc...」宣言は、この記事の上の方にある com.apple.decmpfs アトリビュートにも出ていたが、数値の末尾に、予想通りのデータが見えている：
タイプコード「APPL」とクリエイターコード「emal」（Mail.app用 - Classic MacOSの伝統どおりの可愛らしさ）。
より小さなファイルについて、hfsdebugを使うと：
% hfsdebug /etc/asl.conf
...
compression magic = cmpf
compression type = 3 (xattr has compressed data)
uncompressed size = 860 bytes
この例では、（圧縮してはいるが）拡張アトリビュートにすっぽり格納できるほどデータが小さい。
そして、これが最後のフロンティア：
% hfsdebug /Volumes/Snow Time/Applications/Mail.app/Contents/PkgInfo
...
compression magic = cmpf
compression type = 3 (xattr has inline data)
uncompressed size = 8 bytes
うんうん、拡張アトリビュートに非圧縮なファイルがまるごと格納されているね。
ここで見ているような標準的なPkgInfoファイルは、Classic Mac OS由来のタイプコードとクリエイターコード（各4バイト）を保持しているだけだ。
% xattr -l Applications/Mail.app/Contents/PkgInfo
com.apple.decmpfs:
0000 66 70 6D 63 03 00 00 00 08 00 00 00 00 00 00 00 fpmc............
0010 FF 41 50 50 4C 65 6D 61 6C .APPLemal
「fpmc...」宣言は、この記事の上の方にある com.apple.decmpfs アトリビュートにも出ていたが、数値の末尾に、予想通りのデータが見えている：
タイプコード「APPL」とクリエイターコード「emal」（Mail.app用 - Classic MacOSの伝統どおりの可愛らしさ）。
あなたは不思議に思うことだろう。
これがデータ圧縮のすべてだとしたら、8バイトの非圧縮データ + 17バイトの宣言文字列を拡張アトリビュートに格納することが、ディスクスペースをどのぐらい節約するのか？
HFS+がディスク領域を割り当てる方式に、その答えがある。
データフォークあるいはリソースフォークに情報を格納する際、HFS+は複数のアロケーションブロック（デフォルトでは1ブロックあたり4KB）を確保する。
従来の方法では、8バイトを格納するのに最低4096バイトの領域を占有することになる。
拡張アトリビュート用にディスクスペースが割り当てられるときは、このアロケーションブロックのサイズが関与しないのだ；データはもっとタイトに格納される。
結果的に、これら25バイトのデータを拡張アトリビュートに格納することで、4000バイト以上を節約できる。
しかし、圧縮はディスクスペースを節約するだけではない。
I/Oの遅延や帯域の低下によるCPUの動作待ちは、伝統的なテーマだ。
過去数十年間、CPUのパフォーマンスは向上し続けていて、（そしてコンピュータのリソースは有り余るようになった - 最近は特に）それはディスクのパフォーマンス向上にくらべてはるかに大きい。
現代のハードディスクのシークタイムや回転待ちの遅延は、ミリセカンドのクラスにとどまっている。
1ミリセカンドあれば、2GHzのCPUは200万回サイクルをまわせる。
そしてもちろん、実データの転送時間も無視できない。
ところで、OSやハードウェアによる複数段のキャッシュ技術はこれらの遅延をがんばって隠蔽してくれている。
しかしキャッシュが満杯になってしまえば、ディスクに落とし込まねばならない。
圧縮すれば、転送するべきデータ自体が減る。
現在のマルチコアなMacでは、普通の使い方だとCPUのリソースが笑ってしまうぐらい余っている。
ディスクから圧縮データを転送してCPUがメモリに展開する作業、この総時間は、非圧縮データを転送する時間よりも短いのだ。
これがデータ圧縮のすべてだとしたら、8バイトの非圧縮データ + 17バイトの宣言文字列を拡張アトリビュートに格納することが、ディスクスペースをどのぐらい節約するのか？
HFS+がディスク領域を割り当てる方式に、その答えがある。
データフォークあるいはリソースフォークに情報を格納する際、HFS+は複数のアロケーションブロック（デフォルトでは1ブロックあたり4KB）を確保する。
従来の方法では、8バイトを格納するのに最低4096バイトの領域を占有することになる。
拡張アトリビュート用にディスクスペースが割り当てられるときは、このアロケーションブロックのサイズが関与しないのだ；データはもっとタイトに格納される。
結果的に、これら25バイトのデータを拡張アトリビュートに格納することで、4000バイト以上を節約できる。
しかし、圧縮はディスクスペースを節約するだけではない。
I/Oの遅延や帯域の低下によるCPUの動作待ちは、伝統的なテーマだ。
過去数十年間、CPUのパフォーマンスは向上し続けていて、（そしてコンピュータのリソースは有り余るようになった - 最近は特に）それはディスクのパフォーマンス向上にくらべてはるかに大きい。
現代のハードディスクのシークタイムや回転待ちの遅延は、ミリセカンドのクラスにとどまっている。
1ミリセカンドあれば、2GHzのCPUは200万回サイクルをまわせる。
そしてもちろん、実データの転送時間も無視できない。
ところで、OSやハードウェアによる複数段のキャッシュ技術はこれらの遅延をがんばって隠蔽してくれている。
しかしキャッシュが満杯になってしまえば、ディスクに落とし込まねばならない。
圧縮すれば、転送するべきデータ自体が減る。
現在のマルチコアなMacでは、普通の使い方だとCPUのリソースが笑ってしまうぐらい余っている。
ディスクから圧縮データを転送してCPUがメモリに展開する作業、この総時間は、非圧縮データを転送する時間よりも短いのだ。
転送データ量を減らすことのメリットについて説明したが、ファイルを拡張アトリビュートに格納すると実際に高速化できる。
データの局在性がそれだ。
大きなデータを転送するのにハードディスクが低速になるのは、ハードディスクのヘッドがディスクの別の場所に移動するからだ。
ヘッドの移動開始、停止、狙った場所に正しく静止、ディスクの回転待ち…ヘッド移動のたびにこれらの時間がかかる。
物理的な部品が高速かつ的確に踊る様は驚きだが、限界がある。
一連の動作は、ハードディスクのような回転ストレージにとってはパフォーマンス殺しだ。
HFS+ ボリュームはファイル - メタデータ - のついての全情報をディスクの2つの優先領域に格納する：
カタログファイルには、ファイル情報、アクセス権、所有権、その他諸々など。
アトリビュートファイルには、「named fork」。
HFS+の拡張アトリビュートは、アトリビュートファイル内の named fork という形で提供されている。
ただし、領域を大きく確保できる（ファイルシステムがサポートする上限まで可能）リソースフォークと異なり、HFS+の拡張アトリビュートはアトリビュートファイルに「インラインで」格納される。
そのため、アトリビュートごとの上限は約128バイトになる。
しかし、実データを読み出すのに、ディスクの別の場所にヘッドを移動させなくてもいいわけだ。
ご想像の通り、カタログファイルとアトリビュートファイルがあるディスク領域は頻繁にアクセスされるため、キャッシュされている可能性が高い。
メタデータとデータ本体の両方を含むファイルの格納を、B-tree構造化されているカタログファイルとアトリビュートファイルで完結させるという狙いにより、全体的なパフォーマンスの向上に成功している。
8バイトの領域を25バイトに膨らませていることについてだが、それがデータストレージのアロケーションブロックサイズよりも小さく、また、OSが読み出すべきアトリビュートファイルのB-treeノードに丸ごと格納されているうちは、心配無用だ。
Snow Leopardのディスクスペース節約に大きく貢献している要素は他にもある（例えば、不必要な言語リソースや"designable.nib"ファイルの除去）。
しかしHFS+の圧縮は、技術的に非常に興味をそそられるものだ。
データの局在性がそれだ。
大きなデータを転送するのにハードディスクが低速になるのは、ハードディスクのヘッドがディスクの別の場所に移動するからだ。
ヘッドの移動開始、停止、狙った場所に正しく静止、ディスクの回転待ち…ヘッド移動のたびにこれらの時間がかかる。
物理的な部品が高速かつ的確に踊る様は驚きだが、限界がある。
一連の動作は、ハードディスクのような回転ストレージにとってはパフォーマンス殺しだ。
HFS+ ボリュームはファイル - メタデータ - のついての全情報をディスクの2つの優先領域に格納する：
カタログファイルには、ファイル情報、アクセス権、所有権、その他諸々など。
アトリビュートファイルには、「named fork」。
HFS+の拡張アトリビュートは、アトリビュートファイル内の named fork という形で提供されている。
ただし、領域を大きく確保できる（ファイルシステムがサポートする上限まで可能）リソースフォークと異なり、HFS+の拡張アトリビュートはアトリビュートファイルに「インラインで」格納される。
そのため、アトリビュートごとの上限は約128バイトになる。
しかし、実データを読み出すのに、ディスクの別の場所にヘッドを移動させなくてもいいわけだ。
ご想像の通り、カタログファイルとアトリビュートファイルがあるディスク領域は頻繁にアクセスされるため、キャッシュされている可能性が高い。
メタデータとデータ本体の両方を含むファイルの格納を、B-tree構造化されているカタログファイルとアトリビュートファイルで完結させるという狙いにより、全体的なパフォーマンスの向上に成功している。
8バイトの領域を25バイトに膨らませていることについてだが、それがデータストレージのアロケーションブロックサイズよりも小さく、また、OSが読み出すべきアトリビュートファイルのB-treeノードに丸ごと格納されているうちは、心配無用だ。
Snow Leopardのディスクスペース節約に大きく貢献している要素は他にもある（例えば、不必要な言語リソースや"designable.nib"ファイルの除去）。
しかしHFS+の圧縮は、技術的に非常に興味をそそられるものだ。
インストーラの知性
Appleは、インストールプロセスに二つの興味深い仕掛けを施してきた：
Snow Leopardはあなたのアプリケーションの互換性を確認し、非互換であることが確認されているプログラムをインストール対象から外す。
また、インストールが強制停止された場合でも、データを失うことなしに再開できる。
「非互換であることが確認済」のアプリケーションを除外する。
これは間違いなく、2年前にTigerからLeopardにアップグレードしたユーザの一部に起こった「ブルースクリーン」問題への回答だ。
これは非互換性 - 「許可されていない」サードパーティのシステム拡張 (extensions) が引き起こした。
私はこのような手段を実利的なスタンスで見ることにしている。
Appleが、ユーザへの影響を最小限にする現実的なアプローチをとったことを好ましく思う。
もちろん、非互換かもしれないソフトウェアすべてを検知して無効にするのは無理な相談だろう。
最も人気がある、または最も評判がよいリスキーなソフトウェアを検知するのではないだろうか。
あなたが開発者なら、自身のソフトがAppleのブラックリストに載っているかどうか確認するのに便利だ。
インストールの再開機能についてだが、電源トラブルの後でインストールを継続する時、私はこの機能をテストする気力を失っていた。（UPSは持ってる）
インストールのような長時間のプロセスのことを考えると、この手の堅牢性は歓迎だ。とくにラップトップのようなバッテリー駆動のマシンにとっては。
インストールプロセスのこういった改良の背景には、Appleの開発者がOSの各要素を洗練させることに時間をかけたことがある。
インストーラのチームは2年近くの開発サイクルの間、インストーラを満足なものにするというプレッシャーを受けていたのだろう。
そのへんの実状はわからないが、ユーザーはその成果を受け取ることができた。
Appleは、インストールプロセスに二つの興味深い仕掛けを施してきた：
Snow Leopardはあなたのアプリケーションの互換性を確認し、非互換であることが確認されているプログラムをインストール対象から外す。
また、インストールが強制停止された場合でも、データを失うことなしに再開できる。
「非互換であることが確認済」のアプリケーションを除外する。
これは間違いなく、2年前にTigerからLeopardにアップグレードしたユーザの一部に起こった「ブルースクリーン」問題への回答だ。
これは非互換性 - 「許可されていない」サードパーティのシステム拡張 (extensions) が引き起こした。
私はこのような手段を実利的なスタンスで見ることにしている。
Appleが、ユーザへの影響を最小限にする現実的なアプローチをとったことを好ましく思う。
もちろん、非互換かもしれないソフトウェアすべてを検知して無効にするのは無理な相談だろう。
最も人気がある、または最も評判がよいリスキーなソフトウェアを検知するのではないだろうか。
あなたが開発者なら、自身のソフトがAppleのブラックリストに載っているかどうか確認するのに便利だ。
インストールの再開機能についてだが、電源トラブルの後でインストールを継続する時、私はこの機能をテストする気力を失っていた。（UPSは持ってる）
インストールのような長時間のプロセスのことを考えると、この手の堅牢性は歓迎だ。とくにラップトップのようなバッテリー駆動のマシンにとっては。
インストールプロセスのこういった改良の背景には、Appleの開発者がOSの各要素を洗練させることに時間をかけたことがある。
インストーラのチームは2年近くの開発サイクルの間、インストーラを満足なものにするというプレッシャーを受けていたのだろう。
そのへんの実状はわからないが、ユーザーはその成果を受け取ることができた。
以上です。
実際投稿してみると、分量はそれほどでもなかった…
実際投稿してみると、分量はそれほどでもなかった…
乙！ 原文の内容も翻訳もナイスだ。
とても面白かったです！
一応、気付いちゃったので僭越ながらも訂正しまする
>>404
109バイト（10億） → 10の9乗（10億）バイト
230バイト（10億7374万1824） → 2の30乗（10億7374万1824）バイト
一応、気付いちゃったので僭越ながらも訂正しまする
>>404
109バイト（10億） → 10の9乗（10億）バイト
230バイト（10億7374万1824） → 2の30乗（10億7374万1824）バイト
Blockについての説明も非プログラマーにもわかりやすくて面白かった。
「Cプログラマーたちよ、ようこそ、高階関数の世界へ」。
「Cプログラマーたちよ、ようこそ、高階関数の世界へ」。
ためになりますた
418 ：名称未設定：2009/09/03(木) 22:11:53 ID:jmKMK3mQ0
ありがとう
GJ!