Mac関連ネタを凄い勢いで翻訳するスレ8

**名称未設定** · 2013/11/14(木) 18:07:53.20

[前スレ]
Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7
http://anago.2ch.net/test/read.cgi/mac/1194073058/

Mac関連の英文記事や英文マニュアルなどを、暇な人たちが翻訳するスレッド第８弾です。
「この英文の内容を知りたいんだけど、自動翻訳じゃ意味がｻﾊﾟｰﾘ」という場合に活用してください。

＜＜依頼者へのお願い＞＞
◎翻訳する人はあくまでボランティアです。以下の点にご注意下さい。
・訳文の二次利用はご法度です。
・ご自身のサイトの翻訳はご遠慮下さい。
・あまり長すぎる文章を依頼しないように。
・翻訳してくれる人への感謝の気持ちをお忘れなく。

［過去スレ］
Mac関連テキストをすごい勢いで翻訳するスレッド
http://pc.2ch.net/mac/kako/1020/10204/1020487234.html
Mac関連ネタを凄い勢いで翻訳スレ2
http://pc.2ch.net/test/read.cgi/mac/1035938842/
Mac関連ネタを凄い勢いで翻訳スレ3冊目
http://pc.2ch.net/test/read.cgi/mac/1051925818/
Mac関連ネタを凄い勢いで翻訳するスレ・４
http://pc7.2ch.net/test/read.cgi/mac/1073284076/
Mac関連ネタを凄い勢いで翻訳するスレ5
http://pc7.2ch.net/test/read.cgi/mac/1116278311/
Mac関連ネタをもの凄い勢いで翻訳するスレ 6
http://pc11.2ch.net/test/read.cgi/mac/1140671343/

［まとめサイト］
ttp://kb2m.sakura.ne.jp/log/honyaku/index.html

**シラクサ好き** · 2013/11/14(木) 18:09:22.24

2、なのだろうか。

前スレが512kb制限とやらに引っかかって書き込めないので、
新スレを立てちゃいました。

**シラクサ好き** · 2013/11/14(木) 18:13:51.70

でですね、

>>前スレ824

おおおおお、すごくよく分かった。拙訳ぜんぜん間違ってましたね。公式ドキュメントも勉強に
なった。とてもありがとう。

事情を知らない人でも分かるように親切な訳注をつけるとしたら、長くなるけどこんな感じだろ
うか：

「レイキャスティングシステムとは、ある点からどこかの方向に光線を投射する、と仮定して、
その光線をさえぎる物体が途中にあるかどうかを検知できるシステムのことで、例えばメタルギア
ソリッドでスネークが「！」されるかどうかを敵キャラの視線にもとづいて判定するみたいな処
理が可能になる。

そしてこの手法を使うと、小型で超高速な物体の当たり判定も処理することができる。超高速で
飛ぶ小さい物体、たとえば銃弾とかは、ちょっとの間に長距離を移動する。ゲームの一般的な描
画間隔は1/60秒だが、その間にも弾は数メートルとか進む。もしその数メートルの間に厚さ50セ
ンチの壁があったら、普通の当たり判定法を使うと弾は壁をすり抜けて飛び続けてしまう。普通
の当たり判定とは、描画フレームごとに弾の位置座標を取得して、その座標が壁の厚みの内側に
存在するかどうかをチェックするようなやり方である。レイキャスティングを使うと、こういう
状況でも弾が壁をすり抜けないよう処理することができる。」

どうでしょう。しかし当たり判定一つとってもゲーム技術の進みっぷりはすごいもんですな。

**名称未設定** · 2013/11/15(金) 21:57:39.85

>>1乙

　　〃∩　∧__∧
　　⊂⌒ (　・ω・)　　あーぬこきたぬこ
　　　｀ヽ_つ　 ,.ﾍ_ﾍ
　　　　　　　　(　　　)
　　　　　　　　u,__っ） ))))

　　　　　　　　　　　　　〃∩　∧__∧
　　　　　　　　　　　　　⊂⌒(・ω・`*)　　あ～
　 ,.ﾍ_ﾍ　　　　　　　　　　｀ヽ_っ⌒/⌒ｃ　　　いっちゃうぬこ～
　(　　　)　　　　　　　　　　　　 ⌒ ⌒
　 u,__っ） )　)　)　)　) ノ
　　　　　　　　　　　　　ノ
　　　　　　　　　　　　ヽ
　　　　　　　　　　ヽ
　　　　　　　　　ヽ
　　　　　　　　ヽ
　　　　　　　ヽ　　　　　　　　　ヽ
　　　　　　　ヽ　ノ　）　）　）ヽ

**偽の神** · 2013/11/18(月) 21:01:54.03

arsのMavericksレビュー、エネルギー節約の箇所を途中まで翻訳しました。
arstechnica.com/apple/2013/10/os-x-10-9/12/#energy-saving

エネルギー節約
9年前といえば、Appleがデスクトップ機よりもラップトップ機を多く売ることになった最初の年だ。
最近では、ラップトップ機はデスクトップ機の3から4倍売れるのが普通になっている。
奇妙に思えるが、Appleはバッテリーライフを伸ばすことに強くフォーカスしたOS Xをリリースするのを長々と保留していた。

**偽の神** · 2013/11/18(月) 21:22:33.84

2000年初頭に戻ると、Appleのラップトップ機は同時期のウインドウズラップトップ機とバッテリーライフで引けを取っていなかった。
そして今日、棒グラフは伸びた - しかしウインドウズ機を引き離すほどではなく、Macの10倍売れているiOS製品を引き離してもいない。
3年前にiPadが発売されてから、それのバッテリーライフはAppleの重くて高価なMacラップトップに恥をかかせ続けている。

**偽の神** · 2013/11/18(月) 21:25:29.40

MacラップトップはiOS製品のイメージに合わせて数多く変更されている。
稼働箇所のある部品は削除され（光学ドライブ、機械式ハードディスク）；
着脱可能で、自分で装着できる部品はより小型で専用形状にされた同等品（SSD、バッテリー）に置き換えられ；
そしてロジックボードのチップ数は着実に減っている（単独GPUやノース・サウスブリッジは統合GPUとPCHに置き換えられた）。
これら全てがバッテリーライフの延長につながり、最新のHaswell搭載のMacBookはついにiPadと比較に足るようになった。

**偽の神** · 2013/11/18(月) 21:32:11.12

勝利宣言してもいいかい？いや全然だ。
確かに、最新のラップトップ機のバッテリーライフは10時間に達している…適切な環境では。
問題を理解するには、ラップトップのエネルギー消費者を考えよう：LCD、RAM、SSD、CPU、GPU。（僕たちは3文字言葉が大好きだ）
これら部品は動作時に最低消費電力を要求する。
ディスプレイを完全に切ることもできるが、ユーザーの作業に支障が出る。
保持データを失わないために、RAMは数十ミリセカンドごとにリフレッシュしなければならない。
（データロストのことは考えないようにしよう）

**偽の神** · 2013/11/18(月) 21:34:50.47

問題は動作のために最小限の電力を要求されることではなく、システムが要求する最大電力と最小電力との間に開きがあることだ。
電力の変動において、CPUとGPUを超えるものはない（両方ともHaswellの同じダイ上にある）。
以下のグラフは、Mavericksのエネルギー節約戦略を説明するためにAppleがWWDCで使ったもので、
統合GPUを備えた現代のラップトップCPUの典型的な使用例だ。
（画像）
（TurboラベルはIntel Turbo Boost機能のことで、電力と発熱の許す限りCPUを高速動作させる。）

**偽の神** · 2013/11/18(月) 21:38:21.24

アイドル状態とターボ状態とでは60倍の開きがある。
そして間違いなく、GPU単体からくる15～25Wの持続電力は、新しいMacBookAirの54Wバッテリーからすると恐るべき代物だ。
（計算してみよう） 12時間のバッテリーライフのうち多大な部分を占めている。
アイドル状態と最大稼働状態でこんなに大きな開きがあり、加えて最大電力も非常に大きい、こんな部品はシステム内ではこれだけだ。
スクリーンを暗くしても消費電力が1/60になったりはしないし；
RAM（現在のMacBook、Air、Proではロジックボードにハンダ付け）とSSDが全力動作しても電力を25Wも使いはしない。

**偽の神** · 2013/11/18(月) 21:42:28.95

これらを踏まえて、ソフトウェア的に最も効果的なエネルギー節約術が何なのかは明らかだ；可能な限りCPUのアイドル状態を維持する。
馬鹿馬鹿しい話に聞こえる。Macを使っているときは、CPUはその時間の大半をおそらく入力待ち状態に費やしている。
あなたが驚異的なタイピストで、1分間に120語を打ち込めるとしよう。
だいたい1秒間に10回のキーストロークが発生する。
各キーストロークの間に、2013年MacBookAirの下位のモデルでも数億回のオペレーションを実行できる。

**偽の神** · 2013/11/18(月) 21:44:41.33

もちろん、システムとしてはタイピングがなされてるだけではなく、CPUに対して最も負荷のかかっているものが別にある。
たぶん別のウインドウでは動画が再生されているし；
もしあなたが開発者なら、Xcodeがエラーを検知するために入力されたコードをコンパイルしているだろうし；
メールも届いているだろう；
Spotlightは変更されたファイルをインデックス化しようとしているし；
Time Machineがバックグラウンドで動いているかもしれない。

これが、CPU動作負荷をシンプルに表したものだ。
（画像）

**名称未設定** · 2013/11/18(月) 21:47:57.35

おお、続きが。

**偽の神** · 2013/11/18(月) 21:53:30.21

アイドル時間が大量にあるのが分かるだろうか？しかしこれは実情と異なる。
実際のCPUは動作状態からアイドル状態に即座に移行できない。遷移時間が存在するのだ。
それは長くはなく、またその遅れはこれまでの技術改良により低減され続けているが、ゼロにはなっていない。

実際には、現在のIntel CPUは10～15マイクロ秒でクロックゲートに従って遷移し、
電力が完全に落とされているコアの状態をリストアするのに数千マイクロ秒かかる。

**偽の神** · 2013/11/18(月) 21:59:28.17

上のグラフのX軸のスケールをもう一度見てみよう。グラフ全体は1ミリ秒（1000マイクロ秒）だ。
10マイクロ秒の遷移時間も描かれている。
電力状態の遷移時間をグラフに追加してみよう（もう一度言うが、ひどく単純化した図である）。
（画像）
本当のアイドル時間が劇的に減少した。
動作状態の間にある谷間が小さすぎるときは、CPUはアイドル状態にまったく戻らない。
カーブの下のグレー領域は無駄な時間であり、その量はかなり多い。

**偽の神** · 2013/11/18(月) 22:02:15.72

最初の例を思い出してみよう：キー入力、動画再生、コンパイル、メール受信、バックアップ、ファイルインデックス化。
これらの作業のうちいくつかだけでも、アイドル状態を妨げる高いデッドラインになりうる。
音声と動画の再生についてはCPUの負荷は低いが、再生がガクつかないための基本的な作業は必要になる。
同じように、高速タイピングする人も可能な限り速くスクリーンで結果を見たがっている。
その他もろもろにより、アイドル状態と動作状態とは小刻みに入れ替わる。

**偽の神** · 2013/11/18(月) 22:06:13.81

私たちが全体のうち只の1ミリ秒についてしか考えていないことを思い出そう。
ほんの少し再スケジューリングに手間をかけることで、動作をより効果的な形に再配置することができる。
（画像）
おお、良くなった！
作業を一つの継続した動作へと融合（コアレッシング）することで、遷移時の無駄が最小限にカットされ、アイドル時間が最大化されている。
より良いことに、この戦略はCPUのスピード増加にも効果がある。
もしCPUが同じ量の作業をより少ない時間で終えられるなら、アイドル状態により早く戻れるからだ。（グラフの赤色部分が狭くなる）
これは居眠り競争現象 (race to sleep) と呼ばれている。

**偽の神** · 2013/11/18(月) 22:08:32.19

これがCPUのアイドル時間を最大化する唯一にして最後の戦略だ。
明らかなことはひとつ：トータルの作業が少なくなっている。
バックアップやSpotlightインデックス化のようなバックグラウンドタスクは遅くなる可能性があるが、
洗濯機と同じで、結局のところはやりきるしかないわけだ。
ユーザーによる入力プロセスは避けられない。しかしそれらには、本当に無駄な第三の作業が生じる。

**偽の神** · 2013/11/18(月) 22:11:32.38

メールでのプログレスバーを考えてみよう。バックグラウンドでメールを受信してアップデートする。
もしメールが前面にいなかったら、プログレスバーはおそらく1秒に10回もアップデートする必要はない。
たぶん1秒に1回で十分だ。
あるいは、完全に隠れているWebブラウザのウインドウでアニメーションを再生することを考えてみよう。
そのアニメーションを再生させる必要はまったくない。

経験則が浮かび上がる：
ユーザーにとって、直接的でもなく将来においても利益がないなら、頻度を下げるか；可能であれば、まったく実行しない。

**偽の神** · 2013/11/18(月) 22:14:14.61

エネルギー節約戦略の概要
要約しよう。CPUはMacラップトップで最も電力を食う部品のひとつであるが、
アイドル状態と最大稼働状態との電力消費に大きな開きがある。
故に、CPUのアイドル時間を最大化することはバッテリーライフを伸ばすのにとても効果的だ。
CPUはアイドル状態への切り替えに時間がかかるので、作業を連続させて塊にすることで遷移回数を最小化し、
CPUがアイドルになる総時間を増大させる。
即座にしなくてもよいかユーザーにとって恩恵のない作業を除去することで、総作業時間を減らす。
いま、ついに、Mavericksがこの戦略をどう実装しているかを見てみよう。

**偽の神** · 2013/11/18(月) 22:17:11.26

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

App Nap
App Napとは、AppleがMavericksのアプリケーションに課したエネルギー節約機構を表す言葉だ。
これまでOS Xに追加されてきた多くの新技術のように、App Napもアプリケーションが協調動作するよう新しい開発者向けのAPIが含まれている。
Appleは、Mavericksを構成するアプリケーションとサービスとで広範囲にこれらのAPIが使われることを狙っている。

**偽の神** · 2013/11/18(月) 22:19:22.46

サンドボックスやGrand Central Dispatchのような新技術とは異なり、
Appleはサードパーティの開発者がアプリケーションをApp Nap対応にする時間を与えていない。
Mavericksで動作するアプリケーションはデフォルトでApp Napに対応している。

アクティビティモニタの新しいエネルギータブはプロセスのエネルギー消費を表示し、そこにApp Napの表示も含まれている。
（画像）
アプリケーションがNap状態のとき、そのCPUとI/Oの優先度は低くなり、アプリケーションがあまり作業をしなくなる。
しかし前の章によれば、作業が連続した塊にされているはずだが？

**偽の神** · 2013/11/18(月) 22:21:51.13

前のグラフに戻ろう；過去、現在、そして未来は全て我々の背後からやってくる。
スケジュールされた実作業が実際に行われていると、動作中のアプリケーションはやや負荷が高くなる。
OSが作業完了をアプリケーションごとに追跡してはいるが、新しい作業を過去の作業連続塊に移動させることはできない。
ベストなのは、未来に発生するであろう作業塊に加えるべく実行を遅らせることだ。

**偽の神** · 2013/11/18(月) 22:24:43.96

未来のCPU使用を予測するのは難しい注文だが、それを簡単にするものがひとつある：タイマーだ。
時間の経過（ユーザーの入力に優先して）に反応して変化する、スクリーンに表示されているもの全ては
ひとつかそれ以上のタイマーを背後に持っている。
メニューバーの時計、点滅するテキスト挿入ポイント、ダイアログの明滅するボタンだけでなく、
ネットワークから定期的に情報を引っ張るようなアプリケーション（為替の表示、ニュースリーダー、Twitterクライアント）も含まれる。
そして忘れてはいけない、いまや遍在している Core Animation framework もそう。

**偽の神** · 2013/11/18(月) 23:39:23.89

Mavericksの隅々にあるタイマーは以前に説明したエネルギー節約を実現するために融合（コアレッシング）される。
単一のアプリケーションは同時に多くのタイマーを持とうとする。
システム全体における全てのタイマーのことを考えると、
イベントを整列してアイドル時間に最大限割り込まないようにするのには十分なチャンスが与えられている。

3つのタイマーを考えると、それらのインターバルは以下のようになる。
（画像）

**偽の神** · 2013/11/18(月) 23:52:31.56

イベントの再スケジューリングによりわずかな遅れがかかるが、以下のようにタイマーが融合される。
（画像）
タイマーが融合されるとき、Maverickは他のイベントと整列させるために100ミリ秒近くイベントを遅らせる。
（例示した画像と異なり、Mavericksではタイマーの開始が早まることはない。遅らせるだけだ）
この遅れはユーザーに気付かれてはいけない。
事実、OS Xの過去のリリースでは、優先度の高いプロセスあるいはI/Oタスクが先回しにされるため
タイマーは規定通りの似たような遅れを見せていた。
Mavericksでは、遅れがただ発生するのではなく計画的かつ故意に発生する。

**偽の神** · 2013/11/19(火) 00:03:10.68

エネルギー節約ということについて全てのタイマーが平等に生成されるわけではない。
高頻度のタイマーは最大の電力食いであり、1秒間のうちに大量にイベントを起こして継続的にGPUをアイドル状態から叩き起こす。
App Napがアプリケーションで有効にされていると、タイマーのイベント発生割合が厳格に制限され、
イベントの間に多くの空き秒数を要求するようになる。

**偽の神** · 2013/11/19(火) 00:29:24.17

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

App Nap ポリシー
翻って、Mavericksではアプリケーションリソースに飢えてしまうことでMacが遅く感じられるのではと心配されるかもしれない。
しかしApp NapそしてMavericksのゴールを思い出そう、バッテリーライフを延ばすだけでなく、レスポンスも改善することだ。

App Napをエネルギー守銭奴としてみるよりも、エネルギーを保護するためプロセスを調節する守護者であり、
多くのシステムリソースに可能な限りアクセスすることを保証するものとしてみよう。
成功か失敗かは、アプリケーションがNapするその時と場合はどうなのかという問いにつながる。

**偽の神** · 2013/11/19(火) 00:39:47.64

Mavericksのポリシーは保守的だ。
最初に、普通のCocoaアプリケーションはApp Napに適応する。
先に述べたように、アプリケーションがMavericks用にアップデートするしないに関わらずそうなっている。
Cocoa framework 自身がいくつかのプライベートなシステムコールを呼んで、
プロセスが属しているアプリケーションがApp Napに適応していることをOSに知らせる。

Finder情報での新しいチェックボックスで、アプリケーションごとにApp Napを無効にすることができる―
OS X 10.9 SDKにリンクされていないアプリケーションに限らず。
Mavericks SDKを使う開発者は新しいApp Nap APIを使うことで、
App Napがアプリケーションに与える影響をより細かくコントロールできるはずだ。

**偽の神** · 2013/11/19(火) 01:33:27.54

CocoaアプリケーションはデフォルトでApp Nap対応とされていて、望まない場合は意図して切にしないといけない。
前述したプライベートなシステムコールの存在は、それ以外の普通のGUI Cocoaアプリケーションでない類いのものは
App Nap非対応であることを意味する。

事実、"前面ではない" Cocoaアプリケーション
(例えば、ドックにアイコンが現れないもの― LSBackgroundOnly か LSUIElement Info.plist keyを見てみるとよい）
もまた、App Nap対応ではない。
（バックグラウンドアプリケーション用の、別のエネルギー節約戦略が存在する；あとで説明しよう）

**偽の神** · 2013/11/19(火) 01:36:55.02

App Nap対応の全アプリケーションについて、
Maverickはそれをいつセーフ状態にしてNap状態に落とすか決定するためのヒューリスティック
（set of heuristics、最適解を予測するしくみ）を適用する。
いくつかの要素がこの決定に影響する：
アプリケーションの表示非表示や描画のアクティビティ、オーディオ再生、ユーザー入力イベントの進行、
power assertion APIの使用など。

**偽の神** · 2013/11/19(火) 01:40:13.37

WWDCでのApp Napデモのひとつに、古いxeyesアプリケーションのCocoa実装があった。
シンプルな目玉のペアがカーソルを凝視しつづけるのは電力を食うように感じるが、
こういう無害なアプリケーションは最終的にシステムリソースの公正な共有よりも多くのリソースを使ってしまう。
Xeyesは自身が前面アプリケーションでない時もカーソルを定期的に追跡せねばならず、
マウスの移動に反応してインターフェイスを継続的に再描画しなければならない。

確かに、アクティビティモニタの新しいエネルギー影響―アプリケーションの電力使用を統合表示したもの―によれば、
目玉によるマウス追跡は驚くほど過酷だ。
しかしApp Napのデフォルトのヒューリスティックでは、別のウインドウを目玉の上にドラッグして見えなくすると、
完全にぼやけて、最後にはアプリケーションがNap状態になりエネルギー影響はゼロになる。

**偽の神** · 2013/11/19(火) 01:44:18.17

App Napに影響する要素の正確な重み付けは恐らくMavericksの成熟により変化するだろう。
完全に隠れたアプリケーションがコールを出すのは簡単だ、しかし一般的なケースでは、
OSにとってアクティビティがユーザーにとって重要かを理解するのはそう簡単ではない。
Mavericksが推測を強制されるとき、アプリケーションに負荷がかかってない状態から離れるところでエラーを起こしがちだ。
しかしAppleはOSによる推測をする必要がない方を好むだろう、
それがエネルギー効率についてアプリケーションをチューニングするためのいくつかの新APIを開発者に提供している理由だ。

しかし考察する前に、Nap状態でないときにアプリケーションが良き市民になるためには
開発者の手間がかなり掛かることにも注目すべきだ。

**偽の神** · 2013/11/19(火) 01:47:39.92

エネルギーのベストプラクティス
説明した xeyes デモアプリケーションの実装例は、マウスの位置を定期的に集計しそれに合わせて目玉のグラフィックを更新している。
スムーズなアニメーションのために、集計は1秒間に20～30回行う必要がある。

不幸にも、集計はこのタスクを完遂するのに唯一効果的な方法だ。
カーソルがまったく動いていないときも、アプリケーションはマウスの位置確認を繰り返している―
もし開発者が以前の状態を保持していなければ毎回目玉を再描画する。

**名称未設定** · 2013/11/19(火) 05:25:52.17

>>34
偽の神さん、超乙です

**偽の神** · 2013/11/19(火) 19:00:59.27

OS X はエネルギー効率により長けた global event monitoring を提供する。
（これはMavericksの新機能ではない） OSが既にカーソルを追跡している；個々のアプリケーションがそれをやる必要はない。
アプリケーションは単にカーソル位置についての興味を表明すればよく、あとはOSが位置変更を知らせてくれる。集計は必要ない。
これは、カーソルが動いていなかったりウインドウが隠れていたりアプリケーションがNap状態でないときでも、
xeyesのCPU使用をゼロ近くに下げることができるということだ。

理想的な形だ：アプリケーションは普段何もせず、CPU使用は限りなくゼロに近づく。
これを達成するために、Appleはすべての集計作業を非推奨にした。
システム上の注目すべきイベントはそれを要求するアプリケーションに通達される：
FSEventsはファイルシステムの変更を；
GCD dispatch sourcesはファイルとネットワークI/O、プロセス生成と消滅、シグナルを；
セマフォとロックはプロセスの同期を。

**偽の神** · 2013/11/19(火) 21:07:12.40

アプリケーションが集計作業から免れたら、さらなる効率化のために他に何があるかを考えるときがくる。

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

App Nap API
見てきたように、App Napヒューリスティックは
ユーザーに有用なフィードバックを返さないアプリを特定してエネルギー制限ポリシーを適用する。
しかしこのプロセスは不完全であり、もっと重要なことに、調整されていないアプリケーションはポリシーの適用を認識することができない。

App Napが適用される（実際には約10秒かかる）前に、アプリケーションはApp Nap APIを使ってそれを自分の手の内にできる。

**偽の神** · 2013/11/19(火) 21:16:09.10

可視性
最初のAPIセットは、アプリケーションが閉鎖されて自身で行動する時にそれを発見できるようにする。
アプリケーションはウインドウが見えてないときに閉鎖されたと考えられる。
（メニューバーも内部的にはウインドウだが、アプリケーションが作ったステータスバーアイコンを含んでいない限りカウントされない）
ウインドウの枠が見えていたら、アプリケーションが表示されていると考えられる。
ドックにしまわれたウインドウは表示されているとみなされない。

アプリケーションの閉鎖状態は bit field で提示される（80年代再び！）。
1つのビットが二つの状態を示す：完全に表示されている、完全に隠れている、の二つ。
Appleは将来このAPIをもっと粒度の高いものにするつもりだろう。

**偽の神** · 2013/11/19(火) 21:21:53.47

独立したウインドウのための閉鎖用APIもある。同じルールが適用される：
ウインドウのどこかが表示されていれば、表示されていると見なされる。
アプリケーション閉鎖用APIとして、ウインドウの可視性がたった1ビットのbit fieldで示される。

ウインドウが隠されてユーザーにとってもはや価値のない重い作業を、ただちに断ち切るためにこれらの可視性APIを使うことができる。

重要なことだが、再表示されるとアプリケーションの動作をすぐに復帰させられる。

エネルギー節約は作業の完全な切断によって実現されるので、
App Napによる自動制限によって、単に作業が遅くなるよりももっと劇的なことになる。
アプリケーションは作業量ゼロの理想状態に近づき、アイドル状態または無視される状態のときはシステムリソースを使わない。

**偽の神** · 2013/11/19(火) 21:52:44.29

タイマーの誤差
CPUアイドル状態からの遷移回数を減らすためにタイマーイベントを融合している様子、
App NapがアプリケーションNap状態のときにタイマーの最大発生回数を制限していること、
変化を特定するためにタイマーが非効率な方法を使って集計を完遂していること、などを見てきた。

しかし、厳格な時間ベースの作業がアプリケーションの中核になっているものもある（リマインダー、RSSリーダー、Twitterクライアント）。
タイマーの使用が適切である状態なら、Maverickは誤差を短縮する経路を提供している。
デフォルトで全てのタイマーに許容されている100ミリ秒の遅れよりも優先されるものだ。

**偽の神** · 2013/11/19(火) 22:28:28.43

アプリケーションが10秒ごとにイベントを起こすタイマーを持っていたら、たぶん1秒かそれ以上の誤差は許容範囲だ。
大きな許容誤差を持つタイマーがもっとシステム上にあり、タイマーイベントが融合されるとより大きな柔軟性を持つようになる。
ミリ秒の精度が必要ない場合、
開発者はより大きな誤差値―タイマーインターバルの10%が推奨されている―を適用するよう強く勧められている。

タイマーはまたApp Napの回数制限から明示的に除外することができる。
そのようなタイマーは稀であるべきで、
一定の応答速度が要求されるハードウェアまたはネットワークを仲介するアプリケーションだけが使うようにとAppleは注意している。
これら "厳密な"タイマーでもミリ秒単位の誤差は許容している。そして、ゼロにしないよう強く戒めている。

**偽の神** · 2013/11/19(火) 22:38:11.44

ユーザーのアクティビティ
新しいユーザーアクティビティAPIは、App Napヒューリスティックを改善する方法を提供する。
作業の本体についてシステムに投げかけることができ、それにはシステムログに投げる解説的な文章や他の診断メッセージが含まれている（例えば、pmset -g assertions コマンドの出力など）

アクティビティの最もよくある型は "user-initiated"で、
直接的なユーザー行動の結果として行われている作業という意味だ（ボタンをクリックした、メニュー項目を選択した）。
アクティビティの別の型は、アクティビティを継続させるためにMacがスリープしないよう明示的に要求する。

**偽の神** · 2013/11/19(火) 22:55:52.45

"background" 型は、それがメンテナンス用作業であり時間に厳密でないアプリケーションであることを意味する。
同じアプリケーション内でユーザーが関わっているタスクに絡まないよう、バックグラウンドタスクはより低いCPUおよびI/O優先度になる。

オプションによってアクティビティ型の意味を改変できる：
"latency-sensitive"オプションは過度な遅延を持てないようにする；
表示を不可能にする、またはシステムスリープを不可能にするオプション；
Sudden Termination や Automatic Termination を不可能にするオプション。

**偽の神** · 2013/11/19(火) 23:02:00.39

これらオプションの多くがすでにある power assertions API の良きフロントエンドになっているが、
ユーザーアクティビティを包括することは開発者がpower assertionの開放を忘れることを少なくし、
Cocoaアプリケーションから使うのがより便利になる。

単一アプリケーションが一度に複数のアクティビティ型を持つことができ、
それら全てを考慮してApp NapはアプリケーションをNapさせるタイミングを決定する。

**偽の神** · 2013/11/19(火) 23:12:34.31

エネルギーの不名誉
Mavericksは最後のエネルギー節約トリックを袖の下に隠している。
極端なケースを除いて、CPUサイクルを無駄に燃やすアプリケーションはたいてい自身の再描画なしにそれを行なう。
バッテリーライフが苦しいとき、みんながFlashアニメーションやグラフィック重視のゲームを非難する用意をするが、
真の問題は一見罪のない山ほどのアプリケーションが恒常的に生み出す低レベル浪費物だ：
Twitterクライアント、テキストエディタ、メニューバーの状態表示、環境設定パネル。

アプリケーションがエネルギーを浪費しているかどうか突き止めるため、
Xcodeの新バージョンではエネルギー消費を計測・表示できるツールセットが含まれている。

画像：Xcode 5's energy impact tools.

**偽の神** · 2013/11/19(火) 23:20:10.15

しかし恐らく最も重要なのは、Mavericksのバッテリー状態メニューに、
エネルギーを大食いしているアプリケーションをリストアップする "殿堂入り" セクションが含まれたことだ。

画像：The battery status menu now calls out energy-hogging applications.

アプリケーションがエネルギーの一気消費で遅くなってしまいユーザーからメールが飛んできて開発者が困惑するさまが想像できる。
アプリケーションによっては作業を行うためにエネルギーを大食いする必要がある。

**偽の神** · 2013/11/19(火) 23:31:00.26

おそらく、Appleは（自身のアプリが）殿堂入りするのを避けようとするだろうが、避けられるものではないだろう。
スクリーンショットのように、Apple自身のアプリケーションがメニューに現れる事態もあっさり起こる。
アクティビティモニタのメニューからアプリケーションを選択して、エネルギータブに切り替えると、
有罪アプリケーションがハイライトされる。

この機能が必然的にカスタマーサポートを騒々しくさせるにも関わらず、これはMavericksの最も重要なエネルギー節約機能のひとつであろう。
Appleはここ数年、OS Xの効果的なリソース使用という教義を説き続けている。
ほんのわずか効率的でないアイドル状態を持つアプリケーションを総計することにより露になる静かで寄生的なエネルギーロスというのは、
開発者のモチベーションになりにくい。

**偽の神** · 2013/11/19(火) 23:36:09.74

MavericksでAppleはその問題に取りかかった。
もし開発者が何もしないなら、アプリケーションはApp Napの対象になる；
エネルギーの大食いは平均的なMacユーザーが簡単に見つけられる場所に通知される。
この要素の組み合わせは、最終的には開発者を動かすことになるだろう。（ベストな開発者はすでにアプリケーションを改良している。）
一度バッテリーに対して優しくない様子を見せられたら、
何年もアップデートされていないアプリケーションをユーザーが捨てる要因になるだろう。

**偽の神** · 2013/11/19(火) 23:42:21.61

以上です。量が多すぎて大変でした。
あとバックグラウンドタスクと圧縮メモリの項があるんですが、
まだ翻訳していません。

**名称未設定** · 2013/11/20(水) 00:20:09.43

大変乙
次回も期待

**シラクサ好き** · 2013/11/23(土) 21:13:55.65

偽の神さま激しく乙であります。

順番が変なんですが、圧縮メモリの項を訳してみました。race to sleepの訳は偽の神さま
に合わせてあります。

圧縮メモリ

ttp://arstechnica.com/apple/2013/10/os-x-10-9/17/#compressed-memory

技術オタクのMacユーザーの間では昔から評判が悪いのだが、Appleはマシンのデフォルト
構成だとRAM搭載量が少なすぎる。RAMを容量ぎりぎりのところまで使い続けるようだ
と、Macはひどく使い心地が悪くなる。私などは長い間、Macを買おうとしている友人全
員に、頼むから標準より多めにRAM積んどけよと、ほとんどお願いするみたいに勧めたも
のだ。もちろん皆「ただウェブ見たりメールしたりするだけなんだから、そこまでは」と
言うんだが、SafariやMail、iPhoto、それにiMovieとかを気軽に使うだけでもRAMの使用
量がやばいことになったりするのだ。

使い切っちゃいけないというんだったら、RAMなど一体何のためにあるのか。その、まあ
これはオタクならみんなよく知ってることなのだが、RAMが足りなくなった時、OS Xは
RAM上のデータをディスク上の「スワップファイル」にコピーし始める。そのデータが後
でまた必要になった場合には、ディスクからRAMに書き戻さなければいけない。その時に
RAMがまだいっぱいいっぱいだと、データを書き戻すスペースを空けるためにRAM上のど
こか別のデータをディスクに退避させなければいけない。このプロセスが繰り返されると
「スラッシング」（ttp://ja.wikipedia.org/wiki/スラッシング）と呼ばれる現象が起き
る。RAMとディスクとの間でデータを行ったり来たりさせる作業でシステムがいっぱいい
っぱいになってしまうのだ。

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:15:41.90

（つづき）

RAMからディスクにデータがあふれ出してしまったからといっても、大した問題で
はないように思えるが、とんでもない。ご存じだろう、ディスクから情報を引っ張っ
てくるのがRAMからに比べてどれだけ時間がかかるかを。そう、　数　十　万　倍　
である。SSDなら回転する円盤よりずっと高速だが、それでもRAMよりは数百倍遅
い。

RAMとディスクの性能にはこのような大落差があるため、iOSはスワップファイルを
使わない設計になっている。iOSが目下使用されていないアプリケーションを遠慮な
くkillするのも、そのせいである。OS Xにもアプリの自動終了
（ttp://arstechnica.com/apple/2011/07/mac-os-x-10-7/8/#automatic-termination）
という機能があり、iOSの方向性に沿った変化が若干うかがえはするけれども、現時
点でまだスワップファイルは使われている。しかし、やはり使用は避けたほうがよっ
ぽどいい。

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:17:22.89

（つづき）

パフォーマンスだけの問題ではない。パフォーマンスとエネルギー消費効率は不可分
の関係にある。「居眠り競争」
（ttp://arstechnica.com/apple/2013/10/os-x-10-9/12/#energy-saving）
の概念を思い出してほしい。タスク処理が高速であるほど、Macは低消費電力のアイ
ドル状態に早く戻ることができる。SSDだったらヘッドを動かしたり
（ttp://en.wikipedia.org/wiki/Disk_read-and-write_head）
プラッターを回転させる必要はないが、それでもデータの転送時間はRAMの数百倍も
遅いし、時間とは要するにエネルギーのことなのだ。

RAMを使いきらないための一つの方法は、起動しているアプリの数を減らすことだ。
これにはアプリケーションの自動終了が効く。
（ttp://arstechnica.com/apple/2011/07/mac-os-x-10-7/8/#automatic-termination）
もう一つの手は、動作中のアプリケーションが使用しているRAMの量を減らすことで
ある。

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:19:16.22

（つづき）

長年の間、OS Xは各アプリケーションが自分の確保したメモリ領域を「破棄可能
（purgeable）」と指定できるAPIを提供している。例えば、アプリケーションはリソース
消費の多い処理の結果を破棄可能なメモリ領域にキャッシュしておくことができる。そして
OSは、追加のRAMを必要とした時、そのキャッシュ領域を他の目的のために自由に使うこ
とができる。キャッシュを作成したアプリケーションがその情報を再び必要とした時は、も
う一度計算し直すだけのことだ。

せっかくのメモリ領域にあえて「破棄可能」と印をつけたがるアプリケーション開発者な
ど、いるわけがないと思われるかもしれない。なんだって自分が確保したメモリ領域を進ん
でOSに返してやらなきゃならんのか。だが、OSの言うことは絶対だ。奴は有無をいわさず
RAMを取り返す。破棄可能なメモリ領域を指定することで、アプリ開発者はそういう時にど
のメモリ領域から先に返していくかを選ぶことができるのだ。

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:20:03.50

（つづき）

それでもまだRAMが足りなければ、OS自身のキャッシュや破棄可能メモリ領域が使われ
る。また、メモリマップトファイル
（ttp://ja.wikipedia.org/wiki/メモリマップトファイル）
はディスク上だけの存在に戻せばいい。ファイルシステムのデータ・メタデータのメモリキ
ャッシュも消去できる。

全てのアプリケーションが搾り取られ、全てのOSキャッシュが破棄された後でもなおRAM
の需要が満たされない時、これまでのOS Xはスワップファイルを使いはじめる他に道がなか
った。

Mavericksでは、スワップという最後の手段の前に、もう一つの方法が用意された。圧縮メ
モリである。Mavericksは、メモリ中の最も使用履歴が古いデータを探し、通常、約半分の
量に圧縮する。ご覧あれ、さらなる空きメモリである。

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:23:12.61

（つづき）

Snow Leopardで導入されたHFS+圧縮機能
（ttp://arstechnica.com/apple/2009/08/mac-os-x-10-6/3/#footprint）
と同じく、圧縮メモリはディスク入出力を減らすかわりに比較的大量のCPUサイクルを消費す
る。データの圧縮と展開はWKdmアルゴリズム
（ttps://www.usenix.org/legacy/publications/library/proceedings/usenix01/cfp/wilson/wilson_html/node23.html）
を使った極めて高速なもので、複数のCPUコアを活用して並列的に処理される。

直感的には、マルチコアCPUがRAMのデータをゴリゴリ圧縮するというのは有効な省エネ戦略に
は思えない。しかし人間の直感というのは、現代のハードウェアが実際どのようにエネルギーを
消費しているかについて誤った答えを出すことが多い。思い出してほしい、これは「居眠り競
争」なのだ！RAMと、それよりも数百倍も遅いSSDとの間でのデータ往復を避けることは、もし
RAMの圧縮がSSDへのアクセスに比べてごく短時間で済むとすれば、大勝利といえるだろう。そ
して、RAM圧縮は実際に高速である。だから、大勝利なのだ。

事実、Mavericksはずいぶんスワップファイルを恐れているようだ。下の図は、システムがRAM
容量をほぼ使い切ったあたりでアクティビティモニタのメモリ概要がどうなっているかを示して
いる。

ttp://cdn.arstechnica.net/wp-content/uploads/2013/10/memory-pressure-1@2x.png
（16GBのうち15.99GBを使用中だが、Mavericksはまだ平然とスワップ0バイトを守ってい
る。）

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:24:11.25

（つづき）

この状態でさらにRAMが要求されると、MavericksはOSのファイルキャッシュを手にかけるが、
まだスワップファイルには手を出さない。もっと大量（数ギガバイトとか）のRAMが要求される
と、メモリ圧縮が始まる。最終的にはスワップの使用は避けられない。だが、ディスクへのスワッ
プという最終手段に出る前にMavericksがどこまで行けるのか、とにかく見てみてほしい。

ttp://cdn.arstechnica.net/wp-content/uploads/2013/10/memory-pressure-2@2x.png
（圧縮されたメモリが8.54GBという巨大な量に達したMavericks。ここでついにスワップに数メ
ガバイト手を出している。）

Mountain Lionに同種のメモリ負荷をかければ、すぐに状況は悪化する。RAMが枯渇したとたんに
ディスクへスワップせざるをえなくなり、パフォーマンスが崖から転げ落ちるように低下するの
だ。一方Mavericksは、Mountain Lionよりも数「ギガ」バイト多くのデータをRAMに詰め込むま
で、スワップに触りもしない。

（つづく）

**シラクサ好き** · 2013/11/23(土) 21:30:23.00

（つづき）

圧縮メモリは、Mavericksにとってトリプル・プレイである。一つはパフォーマンス上の利点。
RAMの中でのデータ圧縮・展開は、データをディスク上で読み書きするよりずっと高速に行う
ことができる。ディスクとして使うのがSSDであっても、である。もう一つは、省エネ上の利
点。RAMとディスクの間でのデータ往復に費やす時間が短いほど、システムはアイドル状態を
長時間維持できる。そして最後は、性能の余裕の上での利点。Mavericksは、以前のバージョン
よりもずっと多くの重い処理を、スワップに助けを求める前にこなすことができる。

（以上）

「圧縮メモリ？別に不要じゃんSSD使えば」とか言われたりしたんでしょうか、シラクサ氏。

**名称未設定** · 2013/11/23(土) 23:03:40.49

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

**名称未設定** · 2014/02/18(火) 22:23:55.63

ほ

**名称未設定** · 2014/03/31(月) 07:30:03.88

支援

**名称未設定** · 2014/04/16(水) 23:21:20.28

支援していきたい

**名称未設定** · 2014/04/16(水) 23:29:01.78

紫煙

**名称未設定** · 2014/07/12(土) 11:18:52.83

あげ

**名称未設定** · 2014/10/19(日) 00:33:12.71

シラクサ氏のYosemiteレビュー読みたい
どなたかお願いします

**シラクサ好き** · 2014/10/20(月) 23:59:48.88

>65

シラクサさん、本当はサーキュースって発音するみたいよ。

とりあえずSwiftの部分を訳し始めたので書き込んでみます。

ttp://arstechnica.com/apple/2014/10/os-x-10-10/21/#swift

Swift

ソフトウェア開発というものは常に移り変わっていくもので、一箇所にとどまるということがな
い。ただ、この業界全体を引っ張っていくただ一つの方向性があるとすれば、それは、抽象度の
上昇である。もちろんその歩みは一直線ではなく、停滞期、大飛躍、そして数多くの挫折があっ
た。しかし長期的な傾向は明白だ。

最初期のプログラムは、マシン語で書かれていた。マシン語とは、たいてい2進数か16進数で表
現された数値の羅列である。ここから抽象度のハシゴを一段上がったのが、素の数字ではなく、
文字記号を使ってデータと命令を表現したアセンブリ言語である。次の段階、PascalやCのよう
な言語は、それぞれに固有の命令セットを持つCPU間の違いを吸収し、ハードウェアに依存し
ないインターフェースをプログラマに提供した。そして、そこからさらに進んだJavaやC#のよ
うな言語になると、メモリに直接アクセスするという形をとらずにプログラムが書けるようにな
った。

**シラクサ好き** · 2014/10/21(火) 00:00:38.37

（承前）

アップルの歴史は、ほぼこのようなプログラム言語の歴史とかぶっている。初代マッキントッシュ
はその後のPC業界の流れを決定づけるGUIで1984年に技術的な偉業を達成したが、それでもOSの
大部分はモトローラ製のCPU、68000のアセンブリ言語で書かれていた。以後、Appleがアプリケ
ーション開発のために選んだ言語は抽象度の高いものへと移り変わっていくが、Pascalから始まり
CとC++を経由、Javaにちょっと寄り道して、そしてObjective-Cにたどり着くという、その道の
りは平坦なものではなかった。

抽象度のハシゴを上ったからといって、以前の、より抽象度の低い言語が完全に消えたわけではな
い。現在でも、OSXにはまだアセンブリ言語で書かれている部分がある。CとC++で書かれた部分
は、それよりも多い。そしてアプリケーションの開発者が使うトップレベルのフレームワークはほ
とんどがObjective-Cだ。この違いは連続的なもので、低レベル言語を使うプログラマとコードの
割合は徐々に下がってくる。現代のOSXやiOS上のソフト開発者にフル機能のGUIアプリケーショ
ンをアセンブリ言語だけで書いてくれと頼んでも、鼻で笑われるだけだ。

プログラム言語やAPIには特有の惰性というものがある。ある言語を囲んでユーザーがコミュニテ
ィを形成し、強力なツール群が構築されてくると、前へと進む次のステップを踏み出すのがもはや
難しくなる。この惰性ーーかつてAppleがCoplandプロジェクトに何年もモタついた末に結局リリ
ースさえできず、OS業界でほとんど致命的な遅れをとったことは有名だ。私は2005年、プログラ
ム言語の抽象化をめぐってAppleがまた同じ愚を犯し、他企業に遅れをとるのではないかと警告し
たが、その時に念頭にあったのは、この惰性だ。

**シラクサ好き** · 2014/10/21(火) 00:01:44.59

（承前）

AppleがようやくモダンなOSを手に入れるためには、NeXTの買収とスティーブ・ジョブズの
復帰を待たねばならなかった。では、AppleをObjective-Cの先へ進ませるには、いったい何が
必要なのだろうか。もしAppleが次の一手をすぐに考え始めなければ、2010年にはCoplandの
ような悲劇が待っているのではないかと私は憂慮した。その頃には、全ての競合相手がプログ
ラム言語の抽象度を高めてくるだろうと想定したからだ。

2010年は始まり、そして去った。低レベル言語の使用により、競合するスマートフォン・メー
カーよりもパフォーマンス上優位に立ってモバイル市場で成功していたこともあり、Appleは
依然好調を維持していた。私はタイムライン上の慎重派諸氏から憂慮が杞憂に終わった件を責
められた。それはまさにおっしゃる通りだったのだけれども、それでも私は問題が残っている
と主張し続けた。アップルは、何かをしなければならなかったのだ。

この意見はApple内外のMac、iOSデベロッパーの多くから激しく反対された。当然である。
しかし、Apple社のある一人の重要人物が、最先端をさらに革新する機会を見出し、それをも
のにした。2010年の7月、奇しくも私の「Copeland 2010 再び」という記事が公開された一ヶ
月後、AppleのLLVMコンパイラの開発者であり、当時Apple社開発ツールグループのシニアマ
ネージャとなっていたクリス・ラトナーが、新しいプログラム言語の開発にひそかに着手した
のである。

（とりあえずここまで。続きは時間ができ次第）

**名称未設定** · 2014/10/21(火) 08:07:36.33

>>68
乙です
ありがとう

**名称未設定** · 2014/10/22(水) 13:53:38.96

イラスト描きながら自分の顔を殴るキチガイ。足立区に住んでいる。
http://inumenken.blog.jp/archives/14719181.html

**シラクサ好き** · 2014/10/24(金) 00:08:02.72

（承前）

４年後、Apple開発ツール部門主任となっていたラトナーは、2014年WWDCの基調演説に登
壇。OS XとiOSのための新言語を発表し、集まった数千人の開発者を驚愕させた。驚いたの
は、多くのApple社員も同様だったろう。これがSwiftである。

良くできた推理小説の結末と同じく、Swiftの発表は過去の事件を新たな光で照らし直すことに
なった。プロパティのシンセサイズ (Synthesized properties)、ドット記法 (dot syntax)、ブ
ロック (blocks)、参照カウントの自動化 (automatic reference counting = ARC)、そしてコレ
クション定数 (collection literals)。Objective-Cに長年にわたって順次追加されていったこれ
らの機能は、我々に気づかれることなく、水面下で形成されつつあった新たな存在の輪郭をな
ぞっていたのである。特にARCなどは単なる見た目の問題を大幅に超えていた。当時Swiftが
存在していたとしたら、そのまま採用できたような機能だったからだ。

**シラクサ好き** · 2014/10/24(金) 00:09:49.72

（承前）

ここでSwistの文法と機能を網羅するつもりはない。Appleが無料で ”The Swift Programming
Language” というe-bookを公開しており、そこで事細かに説明されているからだ。公表以
降、Swiftは頻繁に変更が加えられている。e-bookもすでに４度にわたって改定されている。
Appleはアプリケーションの実行バイナリの互換性についてはある程度のガイドラインを示し
ている一方、Swiftの進化に伴ってソースコードは互換性を維持しない旨明言している。

Swiftの最も重要な点は、”The Swift Programming Language” の第１章に書かれている。
Swiftが目指すのは「史上初めてスクリプト言語のような豊かな表現力と楽しさを備えた、業務
開発に耐えるプログラム言語であり、”hello, world” からOS全体までを扱えるよう設計されて
いる。」

この理念はあまりに壮大、というかむしろバカげているほどなので、読者諸氏はまともに取り
合わないか、あるいは黙殺してしまうかもしれない。しかし、これこそがSwiftの構想を理解す
る鍵なのである。

（やっと前置き終わり。そして吾輩はここで寝るのである）

**シラクサ好き** · 2014/10/24(金) 00:20:51.21

（うお、改定、じゃなくて改訂だな）
（げ、なんかe-bookの引用部分が変だな）
（まあお察しください）

**名称未設定** · 2014/10/24(金) 00:33:25.43

おお、追加が
いつもありがとうございます
無理のないペースでやっていただければ

**シラクサ好き** · 2014/10/25(土) 00:21:29.57

>>69
>>74

どもです。

（承前）

Such great heights（「これほどの高さまで」）

Swiftに課せられた使命のうち、一つは分かりやすい。抽象度のハシゴにおいて、Appleの開発
環境を一段上に引き上げ、Objective-Cよりも高レベルに達しなければいけない、ということ
だ。つまり、デフォルトでメモリの安全性が確保されている必要がある。どれほど単調であり
ふれたコードであっても、たった一つポインタの参照先を誤っただけでメモリが不正に上書き
されてしまい、アプリケーションがクラッシュしてしまう（ひどいケースでは改竄されていな
がら動き続けてしまう）ような時代は、もう終わりにしなければならない。

言語の抽象度が上がるというのは、ありふれたタスクが少ない行数で書けるようになり、重要
でない細部は気にしなくてもよくなる、ということだ。下のコードは、50歳以下のApple従業
員をアルファベット順にリストする。JavaScriptかRubyが突然変異したみたいに勘違いされ
るかもしれないが、これはれっきとしたSwiftのコードである。

////////////////////////////////////////////////////////////

let ages = [
"Tim": 53, "Angela": 54, "Craig": 44,
"Jony": 47, "Chris": 37, "Michael": 34,
]

let people = sorted(ages.keys, <).filter { ages[$0]! < 50 }

////////////////////////////////////////////////////////////

**シラクサ好き** · 2014/10/25(土) 00:22:29.20

（承前）

これをもしObjective-Cで書いたとしたら、ARCやコレクション定数といった最近の新機軸を
もってしても、コードは大幅に長くなってしまうだろう。しかも、メモリの安全性を保証でき
るのはプログラマのスキルだけだ。上のコードにはポインタが一切含まれていないが、それ
（とSwiftの境界検査※機能）によって安全性は大きく向上する。

※境界検査 (bounds checking)：
http://en.wikipedia.org/wiki/Bounds_checking

**シラクサ好き** · 2014/10/25(土) 00:23:42.39

（承前）

Swiftは、インド人も納得の高級言語である。基本的なデータ型としては、整数や浮動小数点数
など各種数値、Unicode対応の文字列、配列、そして辞書がある。その全てがプロパティとメ
ソッドを持っている。定数でもそうである。

////////////////////////////////////////////////////////////

if "hello".hasPrefix("he") {
var sillyFour = 5.predecessor()
...
}

////////////////////////////////////////////////////////////

文字列や数値といった標準的なものを含め、全ての型を拡張することができる。ほんの数行の
コード※を追加すれば、例えば 99.bottlesOfBeer() と書いてあの曲※の歌詞を生成することがで
きるのだ。ビールの本数は何本でもいい。

※ほんの数行のコード
（Int型にbottlesOfBeerというメソッドを追加している）：
https://gist.github.com/siracusa/44ffbdef181fc470e761

※あの曲：
http://en.wikipedia.org/wiki/99_Bottles_of_Beer

そのほか、文字列によって初期化されるクラス（例えばURLクラス）さえも拡張可能だ※。た
とば ”http://arstechnica.com”.host と書けば、文字列をURLとしてパースした上で、ホスト
名を取得することができる。

※：
http://nshipster.com/swift-literal-convertible/

**シラクサ好き** · 2014/10/25(土) 00:24:37.44

（承前）

ここまでくれば、高級言語のプログラマもなじみやすく感じるに違いない。しかし話はまだ続
く。豊かな機能を備えていながら、Swiftという言語それ自体は実は非常にミニマルなものだ。
全ての基本データ型は、Swift自身の構成要素ではなく、Swiftの標準ライブラリの一部なので
ある。そして、Swift標準ライブラリはSwiftによって書かれている。

上のコードサンプルにある文字列と数値の定数あるいは変数は、すべて、Swift標準ライブラリ
で定義された基本データ型を用いている。Swiftでは、例えばJavaのようにプリミティブ型と
オブジェクト型をわざわざ区別したりしない。それに、ある型しかサポートしないメソッドや
属性を使うため、その特別な型をわざわざ呼び出す必要もない。全ての型にメソッドと属性が
備わっているからだ。Swiftは外見でいえば、Javaと似ているというより、PythonやRubyなど
が体現する「全てはオブジェクトだ」的な哲学に近い。まして低級言語のCやC++とは大きく
かけ離れた存在だ。

どうだろう、まだ納得がいかないだろうか。Swiftは「スクリプト言語のような豊かな表現力と
楽しさを備えたプログラム言語」を目指していると言うとき、Appleは冗談を言っているわけ
ではない。下のコードを書き込んだテキストファイルは、期待通りに※動作するのだ。

////////////////////////////////////////////////////////////
#!/usr/bin/swift

println("Are you not entertained!?")
////////////////////////////////////////////////////////////

※期待：
http://en.wikipedia.org/wiki/Shebang_(Unix)

**シラクサ好き** · 2014/10/25(土) 00:35:09.75

（Swiftの1ページ目終わったからageさせてもらおう）

**名称未設定** · 2014/10/25(土) 02:46:34.36

いやはや、まじ乙です。

**シラクサ好き** · 2014/10/28(火) 20:36:01.10

Ars Technica
John SiracusaのOS X Yosemite レビュー
Swiftの項目
2ページ目

ttp://arstechnica.com/apple/2014/10/os-x-10-10/22/

Think fast (「高速に考えよ」）

さて、ここからが難しい部分だ。たしかにSwiftは、そのポテンシャルが最大限発揮できた場
合、JavaScriptのような高級言語と肩を並べる簡潔さ、そして使いやすさを実現できるかもし
れない。しかし先に述べた※ように、JavaScriptを高速化するためにApple（や他の面々※）は
これまで大変な労力※を費やしてきた。そして、その途方もない努力にもかかわらず、OS全体
をJavaScriptで書こうと思うような人はほとんどいない。

※先に述べた：
ttp://arstechnica.com/apple/2014/10/os-x-10-10/12/#ftl

※他の面々：
ttps://developers.google.com/v8/

※大変な労力：
https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

**シラクサ好き** · 2014/10/28(火) 20:36:55.21

（承前）

高級言語を安全で使いやすくしている機能は、それゆえに速度の低下を招いてしまうものなの
である。偶然にもSwiftとJavaScriptの両方で動作する、次のコードを検討してみよう。

////////////////////////////////////////////////////////////
var c = a + b // this needs to be fast
////////////////////////////////////////////////////////////

CPUには、二つの数値を足し合わせる命令が備わっている。Cのような低級言語では、整数は
「整数である」と明確に宣言しなければならず、CPUがそのまま利用できるようなフォーマッ
トでメモリに保存される。Cが採用したこの手法の利点は、整数がCPUのADD命令によって直
接操作できるということである。2つの整数を加算するCのコードからコンパイラが生成するの
はまさにこのADD命令に他ならない。

一方、JavaScriptのような言語では、var c と宣言してもそれで有効である。なぜかという
と、JavaScriptの変数は数値や文字列、そしてオブジェクトといったあらゆる値を格納するこ
とができる（「何もない」という値さえ保持できる）からだ。JavaScriptのコンパイラは、上
掲コードの変数aとbに入っているのが数値なのかどうか判断する術がないので、a + b という
コードから単純にCPUのネイティブ命令であるADDを生成することはできない。

**シラクサ好き** · 2014/10/28(火) 20:37:48.54

（承前）

変数に格納されている値の型がソースのコンパイル時に決定できないのであれば、それはプロ
グラムの実行時に決定しなければならない。さらに、もし２変数のいずれかに数値が入ってい
ない、あるいは両者にそれぞれ違う種類の数値が入っている場合には、二つを適切な型に変換
するための処理を追加で実行しないといけない。

JavaScripotでは、+という単純な演算子でさえ意味が状況依存的だ。もし a + b という式でa
が文字列であれば、+演算子は数値の加算ではなく、文字列の結合という処理を実行するのが
正しい。

大事なのは、こうした判断がプログラムの実行中に行われるということだ。JavaScriptエンジ
ンは、コンパイル時に生成されたADD命令を単純に実行するのではない。まずはそもそも何を
すべきなのかを判断するためだけに、数十、あるいは数百の命令を実行しなければいけないの
だ。

もし二つの整数値を加算するために数十のCPUサイクルを消費するようでは、Swiftが「シス
テム開発のための業務に耐える言語」になることなど到底不可能である。この問題を解決する
には、CやObjective-Cのように、Swiftのすべての変数、関数の引数、そして戻り値の型を明
示的に宣言させるのが最良の方法だ。そうすればコンパイラは a + b というコードが何をして
いるのか、そしてどの意味で+演算子を使えばいいのかが分かる。

**シラクサ好き** · 2014/10/28(火) 20:38:29.79

（承前）

確かにそれはそうなのだが、これまで示してきたSwiftのコードでは一度も型宣言が行われてい
ない。私は２年前に、型の明示的宣言なしに変数の型を推定する本格的な型推論※機能が
Objective-Cに盛り込まれるのではないかと推測した。その代わりに登場したのがSwiftであ
る。Swiftは、その目的達成のために型推論に強く依存している。

※型推論：
ttp://www.wikipedia.com/ja/%E5%9E%8B%E6%8E%A8%E8%AB%96

次のSwiftコードで宣言されている変数は、JavaScriptで同じことをした場合と同様、どの型の
値でも保持できるというわけではない。Swiftの各変数は、宣言で代入されている値によってコ
ンパイル時に型が推測され、強制的にその型が付与される。

////////////////////////////////////////////////////////////
var name = "Bob" // String
var cars = 2 // Int
var temp = 88.2 // Double
////////////////////////////////////////////////////////////

**シラクサ好き** · 2014/10/28(火) 20:39:02.68

（承前）

しかしここからが絶妙なのだ。先に述べたように、これらの基本的な型はSwiftという言語の一
部ではなく、標準ライブラリの一部としてSwiftコードによって定義されている。なのでSwift
のコンパイラは、変数carsの型がIntであると分かったとしても、もっと基本的なことを分かっ
ていないのである。つまりIntとは一体何なのだ、ということだ。

Swiftコンパイラは標準ライブラリを漁ってInt型を実装しているコードを探し、コンパイルす
るので、Intというものの存在や、それに何のメソッドが適用できるか、といったことは知って
いる。しかし、IntがSwiftという言語の一部ではないとすれば、コンパイラはInt型の変数を
CPUのADD命令に直接食わせても安全なのかどうか、どのように判断すればいいのだろうか。

もう一つ問題がある。標準ライブラリにはIntに適用できる全ての　演　算　も定義されてお
り、そのコードはSwiftで書かれている。最も基本的な型がライブラリで定義されていること、
そして、定数がそれらの型のいずれかを自動的に付与されることを踏まえれば、Swiftには絶対
に演算子のオーバーロード※機能が必要である。よく批判※の対象になる機能だが、これをサポ
ートしていなければ、Swiftは２整数の加算という単純なコードさえコンパイルできなくなる。

※演算子のオーバーロード：
ttp://www.wikipedia.com/en/Operator_overloading

※批判：
ttp://www.wikipedia.com/en/Operator_overloading#/Criticisms

**シラクサ好き** · 2014/10/28(火) 20:39:38.94

（承前）

ここで先の a + b の例に戻る。整数値をもつ２つの変数があり、それが+演算子で結ばれてい
ると仮定しよう。Swiftのコンパイラは、標準ライブラリをコンパイルするまで、この２変数に
ついて何も分からない。このコードを、２整数を加算するCのコードのように高速にすること
など可能なのだろうか。

////////////////////////////////////////////////////////////
func add(a : Int, b : Int) -> Int {
return a + b
}
////////////////////////////////////////////////////////////

**シラクサ好き** · 2014/10/28(火) 20:46:41.57

（承前）

Swiftのコンパイラswiftcは、上の関数から次のようなアセンブリコードを生成する（コメント
は後から追加）。（「__TF3add3addFTSiSi_Si」というラベルは、add()関数のためにコンパ
イラが生成した名前である。以後このような自動生成名がいくつも登場する。頭がおかしい※
ように見えるが、ここでは気にする必要はない。）

※頭がおかしい名前が必要な理由：
ttps://www.mikeash.com/pyblog/friday-qa-2014-08-15-swift-name-mangling.html

///////////////////////////////////////////////////////////////////////
__TF3add3addFTSiSi_Si:
pushq %rbp ; standard function prologue
movq %rsp, %rbp ; standard function prologue

addq %rsi, %rdi ; add two 64-bit integers

jo LBB0_2 ; jump to LBB0_2 if the addition overflowed
movq %rdi, %rax ; put the result in right register for returning
popq %rbp ; standard function epilogue
retq ; return from the function
LBB0_2:
ud2 ; abort on overflow by raising an invalid opcode exception
///////////////////////////////////////////////////////////////////////

**シラクサ好き** · 2014/10/30(木) 00:55:04.98

（承前）

見よ、燦然と輝くADD命令を！（上下を各２行空けてある。）Swiftのシステムは確かに機能
している。しかし、どのような方法で、なのだろうか。これを詳しく知るには、Swiftのコード
と最終的なアセンブリコードの間にあるものを見ていかなくてはならない。そしてそのために
は、手書きのコードがどのようにして最終的なバイナリに変換されていくのかをもう少し知る
必要がある。

**シラクサ好き** · 2014/10/30(木) 00:55:38.53

（承前）

Swiftのコンパイラシステムの基盤は、LLVMである。驚くべきことではない。LLVMは７年
前、静かにAppleの技術体系に導入され、以後、コンパイラからIDE（統合開発環境）に至る開
発ツール群全体の基盤をなすまでに発展してきた。

上掲のアセンブリコードはx86-64 CPUのためのものだ。このようなハードウェア依存のコー
ドを生成するのは、LLVMベースのコンパイラの最後のステップ※である。この前の段階では、
ある意味架空のCPU、つまり低レベル仮想マシン※のためのコードが生成される。LLVM中間表
現 (LLVM IR) と呼ばれるこのコードは、LLVMオプティマイザによって最適化される。LLVM
IRでの最適化は、プログラム言語にもCPUにも依存しない。このオプティマイザの改善は、す
べての言語、すべての対応CPUに恩恵をもたらすことができる。

※最後のステップ：
http://llvm.org/docs/CodeGenerator.html

※低レベル仮想マシン：
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-December/046443.html

**シラクサ好き** · 2014/10/30(木) 00:56:31.44

（承前）

下の図は、clang（C/C++そしてObjective-Cに対応する、Appleが開発したLLVMベースのコ
ンパイラ）を使ってx86-64 CPUのためのコードをコンパイルするプロセスを示している。

ttp://cdn.arstechnica.net/wp-content/uploads/2014/10/clang@2x.png

Swiftで書かれた先述のadd()関数から、どのようなLLVM IRを生成したのか表示するよう
swiftcに指示しても、llvm.sadd.with.overflow.i64※という命令が呼ばれていると分かるだけ
で、大した情報は得られない。この命令は、先のアセンブリコードにあったx86-64のaddq命
令をLLVMで表現したものであり、両者は結局同じものにすぎない。我々が知りたいのは、二
つのInt型変数を加算するというコードを見て、なぜコンパイラがLLVM IRあるいはx86-64マシ
ン語で、その高速な64ビットのネイティブ加算命令を使おうと判断できたのか、ということ
だ。

※llvm.sadd.with.overflow.i64：
http://llvm.org/docs/LangRef.html#llvm-sadd-with-overflow-intrinsics

**シラクサ好き** · 2014/10/30(木) 01:04:43.75

（昨日は連続書き込み制限を食らったので全部アップできませんでしたが、ここまで翻訳して
あったのでした。）

（あと、>>84の型推論に関するWikipediaへのリンクが間違っていました。以下が正しいで
す。）

http://ja.wikipedia.org/wiki/型推論

（反応をくれた>>80さんをはじめ、読んでくれている人どうもありがとう。訳が変、あるいはこうすればもっと分かりやすい、ということがあればぜひ教えてください。）

（では、おやすみなさい）

**名称未設定** · 2014/10/30(木) 06:17:38.11

乙です。
翻訳に何日掛かったかはわからないけど凄すぎる

**名称未設定** · 2014/10/30(木) 06:45:43.71

シラクサ好きさんの翻訳楽しみにしてます
丁寧な訳で本当に頭が下がります

**シラクサ好き** · 2014/10/31(金) 22:47:27.41

（承前）

Swiftのコンパイラは、コンパイル処理の流れの中に新しいステップを追加し、Swift中間言語
(SIL) という新たな中間形態を導入する。下の図はswiftcを使ってSwiftのコードをx86-64 CPU
のためにコンパイルするプロセスである。

ttp://cdn.arstechnica.net/wp-content/uploads/2014/10/swiftc@2x.png

以下はadd()関数のためにswiftcが生成したSILのコードである。（訳注：コードの太字は再現
できないので、原文を参照のこと）

///////////////////////////////////////////////////////////////////////
// test.add (Swift.Int, Swift.Int) -> Swift.Int
sil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
debug_value %0 : $Int // let a
debug_value %1 : $Int // let b
// function_ref Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
%4 = function_ref @_TFSsoi1pFTSiSi_Si : $@thin (Int, Int) -> Int%5
%5 = apply [transparent] %4(%0, %1) : $@thin (Int, Int) -> Int
return %5 : $Int
}

// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
sil [transparent] @_TFSsoi1pFTSiSi_Si : $@thin (Int, Int) -> Int
///////////////////////////////////////////////////////////////////////

**シラクサ好き** · 2014/10/31(金) 22:48:43.84

（承前）

add()関数の本体にあった a + b は、二つのInt整数を加算する中置記法※ (infix) 演算子の機能を
実装した関数（コード最下部ににその定義が見える）への参照を取得し、add()に与えられた二
つの引数にその関数を適用する、というSILコードに変換されている。このコードでもう一つ
分かるのは、Swift標準ライブラリが「Swift」と名付けられていることである。標準ライブラ
リにおいてInt型はSwift.Intであり、加算演算子はSwift.+であり・・・といったことが見てとれ
る。

※中置記法：
ttp://ja.wikipedia.org/wiki/中置記法

２数を加算するためにSwift.+を呼び出すのは、かなり低速な処理になるかもしれない。上の
SILコードはいわば「素」のSILであり、最適化が無効にされている場合でも、ここからswiftc
によっていくつかのコード変換処理が行われる。次のコード（コメントは後から追加）は、
swiftcが生成したSwift.+関数だけのSILである。Swift標準ライブラリに収められている通り
の、「原典に忠実な※」コードだ。

**シラクサ好き** · 2014/10/31(金) 22:50:45.41

（承前）
///////////////////////////////////////////////////////////////////////
// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
sil public_external [transparent] @_TFSsoi1pFTSiSi_Si : $@thin
(Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
// LLVMの組み込み関数 sadd_with_overflow への参照を取得
%2 = builtin_function_ref "sadd_with_overflow_Word" : $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1)

// 二つの引数のInt構造体から数値を抽出
%3 = struct_extract %0 : $Int, #Int.value
%4 = struct_extract %1 : $Int, #Int.value

// sadd_with_overflow に食わせるもう一つの整数値（１ビット）の作成
%5 = integer_literal $Builtin.Int1, -1

**シラクサ好き** · 2014/10/31(金) 22:51:18.06

（承前）

// sadd_with_overflow_Word を呼んで数値を加算する
%6 = apply %2(%3, %4, %5) : $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1)

// sadd_with_overflow が戻してきたタプル※から結果を抽出
%7 = tuple_extract %6 : $(Builtin.Word, Builtin.Int1), 0
%8 = tuple_extract %6 : $(Builtin.Word, Builtin.Int1), 1

// オーバーフローが起きた場合の対処
cond_fail %8 : $Builtin.Int1

// オーバーフローがなかったら、結果をSwift.Int構造体でラップして返す
%10 = struct $Int (%7 : $Builtin.Word)
return %10 : $Int
}
///////////////////////////////////////////////////////////////////////

※タプル：
ttp://ja.wikipedia.org/wiki/タプル
※原典に忠実な：
canonicalという単語の訳である。「素のSILコードにインライン変換などの処理が適用され
た、オプティマイザが最適化を加える前の状態」を比喩的に表現したものと解釈したが、自信
なし。

**シラクサ好き** · 2014/10/31(金) 22:53:05.34

（承前）

コードが少しややこしくなってきたが、もうすぐ核心部に入るので、どうか付いてきてほし
い。注目は、上のコードで何回も出てくるBuiltinという言葉である。関数
sadd_with_overflow_Wordは、二つのBuiltin.Word型の値（と１つの１ビットブーリアン値）
を引数に取る。ここでsadd_with_overflow_Wordに渡されている二つのBuiltin.Word型の値
は、Swift.+関数に渡されたInt型の引数から抽出されたものだ。

Int型という高レベルの世界と、LLVM IRやその帰結であるマシン語コードという低レベルの世
界とを橋渡しするもの、その大雑把な概要がここで見えてきた。説明に「無限に積み重なる亀
※」は不要だ。各Int構造体がBuiltin.Word型の値を内包しており、それはLLVM IRにおいて直
接に相当する型が存在するほどに十分抽象度が下げられているのだ。

※無限に積み重なる亀：
ttp://en.wikipedia.org/wiki/Turtles_all_the_way_down

**シラクサ好き** · 2014/10/31(金) 23:26:50.66

（承前）

そして、add()関数のコードから生成された最適化前のSIL（先の「素」の状態の次の段階）を
見れば、パズルの最後のピースが埋まる。このコードには、上掲のSwift.+関数のコードすべて
がインライン展開されている。

///////////////////////////////////////////////////////////////////////
// test.add (Swift.Int, Swift.Int) -> Swift.Int
sil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
debug_value %0 : $Int // let a
debug_value %1 : $Int // let b
// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int inlined below
%4 = builtin_function_ref "sadd_with_overflow_Word" : $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1) // user: %8
...
%12 = struct $Int (%9 : $Builtin.Word)
return %12 : $Int
}
///////////////////////////////////////////////////////////////////////

この自動的なインライン展開を制御しているのはtransparent（透明）属性である。前掲のコー
ドでSwift.+関数に付けられていたものだが、気づかれただろうか。

（また連続投稿で弾かれてます。仕方ないのでおやすみなさい。>>92さん>>93さんコメント
ありがとう）

**シラクサ好き** · 2014/11/02(日) 01:13:52.58

（承前）

ここで、ようやくすべてのピースが出揃った。BuiltinはSwiftとLLVM IRの間の橋渡しである。Builtinが表現する型や関数
は、LLVM IRの型※と命令※に直接対応している。transparent属性は、それが必ずインライン展開されるべきプリミティブな
関数であることを示している。Builtinの型を使ってBuiltinの関数を呼び出すSILコードから、LLVM IRのコードを生成するの
は単純な手続きである。Builtin.Word型はLLVM i64型（あるいは、32ビットアーキテクチャ向けのコードならi32型。SILは
LLVM IRよりもアーキテクチャ非依存）に一直線に対応するし、sadd_with_overflow_Wordはllvm.sadd.with.overflow.i64※
というLLVM IRの組み込み命令※にそのまま変換される。他も推して知るべし。

※LLVM IRの型：
ttp://llvm.org/docs/LangRef.html#type-system
※LLVM IRの命令：
ttp://llvm.org/docs/LangRef.html#instruction-reference
※llvm.sadd.with.overflow.i64：
ttp://llvm.org/docs/LangRef.html#llvm-sadd-with-overflow-intrinsics
※組み込み命令：
ttp://llvm.org/docs/LangRef.html#intrinsic-functions

ここまでの検討で、もう一つのことが明らかになる。Swift標準ライブラリは、デフォルトで読み込まれるということを除い
ても、実は少し特別である。Swiftで書かれてはいるが、標準ライブラリはBuiltinの関数と型の世界にアクセスできる唯一の
存在なのである。それに、transparent属性を使って特定の関数を自動でインライン展開するよう指示したりもしている。

**シラクサ好き** · 2014/11/02(日) 01:14:32.80

（承前）

Swift標準ライブラリのソースコードは非公開なので、以上のことを発見するには自作のSwiftコードから生成されたSILを見
ていかなければならなかった。しかし安心してほしい。BuiltinとtransparentはSwift自身の一部であり、SILだけに限定され
たものではない。Xcode6のアプリケーションバンドル内に埋もれているswiftcのバイナリファイルをstringsコマンド※で見て
みると、-parse-stdlibというオプションの存在が見える。このオプションをつければ、Swiftのコードは標準ライブラリと同
じルールに基づいてコンパイルされるので、Builtinの型と関数の使用が許される。Swiftで書いた関数に@transparent属性を
追加し、それをインライン展開するよう望むこともできる。

※stringsコマンド：
ttp://www.unix.com/man-page/osx/1/strings/

わけあって、これらの機能はみなドキュメントには記載されておらず、Swift標準ライブラリの中でしか使用が許されていな
い。Swiftの表の顔ではないものの、その目的を達するために必要な機能である。特にBuiltinは、Swiftの型という高レベルの
世界とLLVM IRという低レベルの世界を結ぶ不可欠な存在だ。もしSwift標準ライブラリがその務めをしっかり果たせば、そ
れが高速化と効率化のためにどのようなテクニックを使っているかを開発者はまったく意識しないですむだろう。

**シラクサ好き** · 2014/11/02(日) 01:16:17.21

（2ページ目が終わったのでageさせてもらいます。）

**シラクサ好き** · 2014/11/02(日) 01:18:12.81

Ars Technica
John SiracusaのOS X Yosemite レビュー
Swiftの項目
3ページ目
ttp://arstechnica.com/apple/2014/10/os-x-10-10/23/

Whither SIL?（「SLIの向かう先」）

そもそもSILがなぜ存在するのかは、一考に値する問題だ。前ページの単純な整数加算の例からは分からないが、SILでは、
SIL固有の、新しい種類の高レベル最適化が施される。それは、もともとのソースについてLLVM IRよりも多くの情報を保持
している表現形態の上でなければ不可能な最適化だ。

Swiftがジェネリックプログラミング※に対応していることを利用した、次のコードを見てほしい。

////////////////////////////////////////////////////////////
func identity<T>(x : T) -> T { return x }

func testInt() -> Int { return identity(42) }

func testDouble() -> Double { return identity(42.0) }
////////////////////////////////////////////////////////////

※ジェネリックプログラミング：
ttp://ja.wikipedia.org/wiki/ジェネリックプログラミング

**シラクサ好き** · 2014/11/02(日) 01:18:58.48

（承前）

最適化を無効にすると、このコードはジェネリックなidentity()関数と、それを別個に呼び出すtestInt()関数・testDouble()関
数を含んだSILを出力※する。最適化を有効にすると、testInt()とtestDouble()は必要に応じた（そしてずっと短い）実装とな
り※、どちらもidentity()関数を全く呼ばないで済んでしまう。

※最適化されていないSILコード：
ttps://gist.github.com/siracusa/6085684045410246c513
※最適化されたSILコード：
ttps://gist.github.com/siracusa/4bf95e485948826af940

この種の最適化は、ジェネリックプログラミングをサポートする言語のコンパイラであれば当然行えるべきものだ。同時に、
これはLLVM IRではやりにくい、あるいは不可能なタイプの最適化でもある。

**シラクサ好き** · 2014/11/02(日) 01:29:36.47

（承前）

LLVM IRとは違い、SILを経由する言語は現状ただ一つしかない。”Swift” Intremediate Languageという、その名称から分か
る通りだ。SILコードとSwiftコードはよく似ている。同じ名前の付いた同じライブラリをインポートするほどである。この二
者の近似性は、LLVM IRとCあるいはC++の近似性よりもずっと高い。SILはある意味高レベル仮想マシンだが（いや、その
こと※ではない。あれ※でもない）、Swift以外の言語のコンパイル先として設計されているわけではない。（JVM※やCLR※と
違い、SILはARC※の処理を露出しているのでメモリは安全ではない。）

※そのこと：
ttps://llvm.org/svn/llvm-project/hlvm/
※あれ：
ttp://www.ffconsultancy.com/ocaml/hlvm/
※JVM：
ttp://ja.wikipedia.org/wiki/Java仮想マシン
※CLR：
ttp://ja.wikipedia.org/wiki/共通言語ランタイム
※ARC：
ttp://arstechnica.com/apple/2011/07/mac-os-x-10-7/10/#arc

（ここで連投チェック入りました。無念）

**シラクサ好き** · 2014/11/03(月) 12:16:18.89

（承前）

先に述べたように、AppleはSwiftの構文法が将来変更されることを明言している。（おそらくAppleは古いSwiftコードを新し
い構文に変換するツールを提供するだろう。）Swiftに固有の最適化を施しながら、Swiftの構文とLLVM IRの生成との間に余
計な結びつきを作らない方法を、SILは提供している。（Swiftよりはるかに構文の安定したCベースの言語をコンパイルする
Clang※は、抽象構文木※から直接LLVM IRを生成する）

※Clang：
ttp://arstechnica.com/apple/2009/08/mac-os-x-10-6/9/#llvm-clang
※抽象構文木：
ttp://ja.wikipedia.org/wiki/抽象構文木

SILは現時点で与えられている役割の範囲内でも目に見える利益を生んでいるが、構文に依存しない、固有のオプティマイザ
を持つ高レベルの中間形態というのは、明らかに何かのポテンシャルを秘めた技術であるように見える。もしかしたらSILに
はさらに大きな目的があり、それはまだ明らかにされていないのかもしれない。

**シラクサ好き** · 2014/11/03(月) 12:16:59.41

（承前）

Frameworks integration（「フレームワークの統合」）

Swiftは全くの新言語ではあるが、Appleはこれが既存のOS XならびにiOSのフレームワークとともに機能するよう体制を整
えている。この点に関しても、”Using Swift with Cocoa and Objective-C※”という無料のe-bookが出版されている。Apple
の既存フレームワークはCとC++、そしてObjective-Cで書かれている。そしてこれらの言語はポインタを使用し、メモリに
直接アクセスする。

※Using Swift with Cocoa and Objective-C：
ttps://itunes.apple.com/us/book/using-swift-cocoa-objective/id888894773

よく練られた一連の表記慣例（と、in-out引数※などのSwiftの機能）を通じて、ほとんどのObjective-C APIはポインタ操作
なしにSwiftコードの中で直接使うことができる。多くのSwiftのデータ型も、それに相当するCocoaのデータ型と入れ替え可
能である。Xcodeは、Objective-CのコードがSwiftのライブラリにアクセスできるよう適切なヘッダファイルを自動生成す
る。Objectivc-C APIのドキュメントをSwift対応に翻訳したものまで、Appleは提供している。

※in-out引数：
ttps://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html

**シラクサ好き** · 2014/11/03(月) 12:18:03.82

（承前）

しかし、慣例と翻訳では済まない面もある。低レベルのC/C++ APIに関しては特にそうだ。このレベルでの統合を可能にする
ため、何と、Swiftは一連のポインタ型の使用を通じたメモリへの直接アクセスをサポートしている。

（ポインタ型にはUnsafePointerやCOpaquePointerのように恐ろしげな名前が付けられている。適切な名称だ。）この対策
は必要な妥協であり、Swiftの他にも例えばC#のような、デフォルトでメモリの安全性が確保された言語で採用されている。

Swiftはあまりに新しく、またあまりにも秘密にされてきたので、YosemiteにはまだSwiftで書かれた大規模なフレームワーク
やアプリケーションが存在しない。しかし、Appleの構想は明らかにそれを志向している。アプリケーションであればSwiftで
書かれていてもユーザーは変化に気づかないかもしれないが、フレームワークは、Swiftの言語的慣例や機能を踏まえて推測
すれば、現在の最もモダンなObjective-Cフレームワークと比べても大きく異なった外見を呈するだろう。これこそ、将来に
向けてAppleが築こうとしている世界である。もっとも、そこへの移行には長い時間がかかるだろう。

**シラクサ好き** · 2014/11/03(月) 12:18:48.29

（承前）

The shape of the future（「将来の姿」）

プログラム言語の設計とは何かといえば、開発者が目的を実現するために何をタイプするべきかを決めることだ、と考える人
がほとんどだろう。機能や意味体系、安全性、そして構文について激しい議論が戦わされるかもしれないが、その行き着く先
は一つの言語仕様である。あるいはそこまで行かないとしても、少なくとも何らかのリファレンスドキュメントは成立するだ
ろう。開発者はこれを見て判断を下す※。この言語は冗長すぎないか。意味体系は理解が難しいのではないか。妙な例外的状
況※は多すぎないか。変な文字※が多すぎないか。複雑さが自己目的化してしまっている※機能はないか。

※ある開発者の判断：
ttp://owensd.io/2014/09/24/swift-experiences.html
※例外的状況：
ttps://www.destroyallsoftware.com/talks/wat
※変な文字：
ttp://www.perl.org/
※自己目的化した複雑さ：
ttp://matt.might.net/articles/c++-template-meta-programming-with-lambda-calculus/

ネットを見て回ればこのような議論がいたるところに溢れているが、その多くはオプショナルな値※やアクセスコントロール※
など、ここでは触れさえもしなかったテーマに関するものだ。プログラム言語の構文や意味体系についてああでもないこうで
もないと論じるのは、開発者にはおなじみの心地よい暇つぶしである。また、言語の設計者が新言語を作るときにこうした問
題について検討するのも当然頷けることだ。

※オプショナルな値：
ttp://airspeedvelocity.net/2014/08/17/implicitly-converting-functions-to-return-optionals/
※アクセスコントロール：
ttp://owensd.io/2014/08/21/protected-swift.html

**シラクサ好き** · 2014/11/03(月) 12:20:22.15

（承前）

Swiftの場合は、少し事情が違う。もちろん、プログラマの立場から見てObjective-Cよりも生産的で楽しいと思えるように設
計されたことは確かだ。柔軟で拡張可能でありながら、大切な安全性も確保できるように考えられている。しかし、Swiftは
コンパイラ技術者が開発したものでもある。

プログラマが何をタイプすべきかを決めることは、Swiftの設計の出発点でも到達点でもない。これは、言語の構文から始ま
ってマシン語のコードにまで達する奥行きを持った構想なのだ。Swiftが機能を採用するにあたっては、ただプログラマにど
んな経験を与えるかということだけが考えられたわけではなく、コンパイルのプロセスで何を可能にするのか、あるいは生成
するのかということも考慮されている。Swiftの開発はアカデミックな営みではない。意味論的な純粋さ、あるいは数学的な
美しさを目指しているわけではない。開発の第１日目から、Swiftは実行バイナリをどう実装するかが念頭に置かれていた言
語なのである。

このアプローチは、設計者の人間性や価値観、あるいはスキルの単なる副産物ではない。実行バイナリの実装に力点を置いた
ことは、「スクリプト言語のように楽しく表現力豊かで、同時に、低レベルのシステム開発言語のように高速で効率的である
べし」と宣言されているSwiftの使命から導かれた、当然の帰結である。

Swiftは、高レベル言語の構文と意味体系を備えた低レベル言語を作ろうという試みである。「十分に賢いコンパイラ※」の神
話に真っ向から取り組み、言語の設計プロセスの一環としてそのようなコンパイラを作り上げようと名乗りを上げている。

※十分に賢いコンパイラ (Sufficiently Smart Compiler)：
ttp://c2.com/cgi/wiki?SufficientlySmartCompiler

**シラクサ好き** · 2014/11/03(月) 12:39:04.91

（承前）

Swiftの実行速度を保証する主要な手段は、静的コード解析※である。開発チームはこの技法に関して既に経験を持っている
※。変数の型の手動指定を不要にする型推論から、SILとLLVM IRの二段階で施される最適化に至るまで、Swiftのあらゆる機
能を可能にしているのは、コードを実行することなしに解析できるこのコンパイラの能力なのである。

※静的コード解析：
ttp://ja.wikipedia.org/wiki/静的コード解析
※開発チームの過去の経験：
ttp://arstechnica.com/apple/2009/08/mac-os-x-10-6/9/#static-analyzer

Builtinというモジュールを通じて、標準ライブラリの最も基本的な要素をLLVM IRのプリミティブな要素に直接ひも付けする
という手法は、Swiftとそのコンパイル環境とがいかに密接に関わっているかを示している。基本的な型をLLVM（最終的には
マシン語コード）という岩盤にネジ止めする、太く、目に見えないこれらのボルトがなければ、SwiftのパフォーマンスがCや
Objective-Cに迫ることはできなかったであろう。

ある意味で、Swiftのこの側面はC++の「コストゼロの抽象化※」の理念と似ている。異なるのは、Swiftが低レベルでのデー
タや命令のやりとりを標準ライブラリに限定し、プログラマにはそのシステムの舞台裏を開示しないという点だ。

※コストゼロの抽象化 (zero-cost abstractions)：
ttp://electronicdesign.com/dev-tools/interview-bjarne-stroustrup-discusses-c

（ここで連投規制入りました）

**名称未設定** · 2014/11/03(月) 12:42:48.32

おお、今日も続き来てる。規制解除。

**シラクサ好き** · 2014/11/03(月) 12:47:52.34

>>112 おお、助かる。

（承前）

バイナリの実装だけではなく、プログラマが直接関わる側面でも、Swiftはソフトウェア開発についての具体的な理念を体現
している。私はソフトウェアを書くことを職業として１８年になるので、プログラム言語の設計について自分なりの確固たる
意見を持っている。例えば、ボタンを押したらどのウィンドウが開くか、あるいはデータベースにどのデータを出し入れする
か、などといったことを制御する高レベルなコーディングをする際に、データの型に関してあれこれするコードを書くのはほ
とんど無駄な労力※だと思っている。

※無駄な労力：
ttps://sites.google.com/site/steveyegge2/is-weak-typing-strong-enough

Swiftの型推論機能はこの苦痛をある程度軽減してくれるが、Swiftの型決定が本質的には静的であるという事実は変わらな
い。型決定を静的にするか、あるいは動的にするかは、このそれぞれのアプローチがコンパイラの実装にどのような影響を与
えるかという観点だけから決まるわけではない。それは、何が「いいコード」なのかを判断する哲学的な選択眼の問題でもあ
る。おそらく、むしろこちらの方が大きいかもしれない。

そういう意図があったのかどうかはともかくとして、Swiftが私の不満を吸収してくれたのは、その設計理念が具体的な言語
仕様として結実した成果のおかげである。私はSwiftの野心的な目標に敬意を持っているし、その目標達成のため、Swiftの各
機能がそれぞれに不可欠であることも理解している。

Swiftに対する最も強い批判は、究極的にはその目標の問題だ。もし「業務に耐えるシステム開発言語」となることを諦めれ
ば、Swiftはもっと親しみやすい高レベル言語になりえたはずだ。逆に、もし単に「より良いC※」になることだけを目指して
いたなら、もっと簡潔な言語になりえただろう。Swiftが今やっていることを、たとえ試みにもせよやってみた言語はこれま
でにほとんど存在しない。難度は高く、そしてそれは自らが課す困難だ。これはつまり、まさにAppleらしい挑戦なのであ
る。

※より良いC：
ttp://golang.org

**シラクサ好き** · 2014/11/03(月) 12:48:44.01

（承前）

もしこれがAppleの基調講演だったら、ここでTim Cookがステージに戻ってきて、Swiftのようなものを作り出せるのは
「Appleだけだ※」と説くところである。さすがにそれは少し誇張があるかもしれないが（MicrosoftのC#※やCLR※を見
よ）、SwiftのようなプロジェクトはAppleの野望にぴったりだし、垂直的な統合を目指す社の長い伝統にも沿うものだ。

※Appleだけ：
ttp://daringfireball.net/2014/06/only_apple
※C#：
ttp://ja.wikipedia.org/wiki/C_Sharp
※CLR:
ttp://ja.wikipedia.org/wiki/共通言語ランタイム

Swiftの構想が、ソースコードから始まって最終的なマシン語コードに及ぶ、ばかりでなく、そこからさらに広がって、CPU
そのものの設計にまで達するのではないかと考えるのは、決してうがち過ぎな想像ではない。歴史をさかのぼれば、古くは
PowerPC、現在のx86、そして最近ではARMプロセッサ、それぞれに固有の特徴が、関数コールの慣習※からObjective-Cラ
ンタイムの機能※に至るまで、Appleのシステム基幹部分の効率性に影響を与えてきた。私は、コンパイラやプログラム言
語、そしてランタイムスタックと直接に結びついた機能をCPUに搭載するよう、Appleは各メーカーにロビーイングしている
（あるいは、自ら設計したチップに対しては、直接実装してしまっている）に違いないと睨んでいるし、このような動きは将
来もっと活発になるのではないかと思っている。

※関数コールの慣習：
ttps://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html#//apple_ref/doc/uid/TP40002437-SW1

※Objective-Cランタイムの機能：
ttp://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html

**シラクサ好き** · 2014/11/03(月) 12:49:47.52

（承前）

一連のコンパイラツールのうち、Swiftに固有の部分は、ClangやLLVMと違ってオープソースではない。それを大々的に使う
企業が自分だけだとしても、AppleにはSwiftを確実に成功させるためのリソースと影響力がある（Objective-Cの例を見
よ）。しかしApple社内には、間違いなくSwiftをオープンソース・プロジェクトにしたい意向を持っている有力な派閥が複数
存在する。これまではとにかくYosemiteとiOS 8をリリースすることが優先事項だったようだが、今後、私はこの問題が再び
検討の対象になるのではないかと考えている。

PowerPCからIntelプロセッサへの移行以来、SwiftはAppleの開発プラットフォームにおいて最も重要な変更である。経験豊
かなObjective-Cプログラマから想定通りの反発※があったのは事実だが、Swiftは単なる変化ではない。安全性、表現性、機
能、そしておそらくパフォーマンス※※の上でさえも、飛躍的な大進歩である。しかもこれ、全てがまだリリース1.0の時点で
実現してしまったのである。

※想定通りの反発：
ttp://mjtsai.com/blog/2014/08/18/its-a-coup/
※パフォーマンス１（Swiftは速い）：
ttp://www.jessesquires.com/apples-to-apples-part-two/
※パフォーマンス２（いやそんなことはない）：
ttp://blog.metaobject.com/2014/09/no-virginia-swift-is-not-10x-faster.html

Swiftはまだとても幼い。しかし前方には明るい将来が開けている。もしこれが成功すれば、サーバーサイドのプログラミン
グからインストーラスクリプト、あるいはウェブ開発に至るまで、Appleのすべての技術スタックに利益をもたらす可能性が
ある。ただ、そもそもObjective-Cの後継者としての役割がそれ自体ですでに十分価値のあるものだ。Objective-Cはこれま
でに数多くの機能拡張を果たしてきたものの、Appleの開発プラットフォームが向こう数十年にわたって安泰であるという保
証には決してならなかった。しかし、Swiftなら、Appleの今後の命運※を明るく照らしてくれるかもしれない。

※Appleの命運への危機感：
ttp://arstechnica.com/apple/2010/06/copland-2010-revisited/

**シラクサ好き** · 2014/11/03(月) 13:00:16.50

（やっとSwiftの項目終わったのでageます。こちらからは以上です）
（しかし「バイバイさるさん」、って腹たつわー）

**名称未設定** · 2014/11/03(月) 13:00:54.66

乙です。
技術者でもないのにこういうの読むのが好きなので、
翻訳してくれてほんと嬉しい。ありがとう。

**シラクサ好き** · 2014/11/13(木) 20:28:28.91

Siracusaさんの発音はサーキュースではなく、サーキューサ、ですね。

**名称未設定** · 2015/02/20(金) 00:40:23.29

ほ

**シラクサ好き** · 2015/04/18(土) 17:42:37.19

Siracusaさん、もうOSXレビューやめちゃうんだと。残念。最高だったよ。

http://hypercritical.co/2015/04/15/os-x-reviewed

**名称未設定** · 2015/05/17(日) 14:34:58.62

それは残念

**名称未設定** · 2015/11/20(金) 07:17:57.28

**名称未設定** · 2015/12/19(土) 07:50:51.23

保守してれば、きっと誰かが。。。

**名称未設定** · 2015/12/20(日) 00:29:32.99

Siracusaさんの離脱が痛いよねぇ

**名称未設定** · 2015/12/22(火) 07:27:56.52

和訳されないネタってのも減ってきちゃったしねえ

**名称未設定** · 2015/12/22(火) 13:48:58.38

ハーベスト HARVEST （マイクロネット）
http://ameblo.jp/koorogiyousyoku/entry-11484199283.html
http://ameblo.jp/koorogiyousyoku/entry-11485481197.html
http://ameblo.jp/koorogiyousyoku/entry-11486255185.html
あのスティーブ・ジョブス氏に
「私はapple2が最高のPCだと思っていた。
　それはロードランナーが最初に発売されたPCだからだ。
　しかし日本のPCに"ハーベスト"というゲームがあることを知り
　その考えは変わった。」
とまで言わせたあのハーベストを紹介するよ！

**名称未設定** · 2016/02/16(火) 16:42:33.66

Apple幹部、「Apple Music」のユーザー数や「Apple TV」新機能をポッドキャストで語る
http://www.itmedia.co.jp/enterprise/articles/1602/15/news062.html

>この他、2人がAppleのサービスのβテストを家族中で行ってリアルなフィードバックを得ていることや、
>Appleの「マップ」の改善について、iOSのβプログラムについて、アプリの品質が低下しているという
>ウォルト・モスバーグ氏の指摘に対する考えなどをオープンに語った。

>このPodcastはこちらで聴ける。
http://daringfireball.net/thetalkshow/2016/02/12/ep-146

翻訳されてない部分が気になる。

**名称未設定** · 2016/03/18(金) 22:22:19.25

**名称未設定** · 2016/07/07(木) 03:21:13.25

保守

**名称未設定** · 2017/01/31(火) 23:47:43.49

ほ

**名称未設定** · 2017/02/01(水) 00:52:16.05

捕手

**名称未設定** · 2017/04/09(日) 23:06:55.23

スレ立て荒らしがいるようなので保守