TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
Yosemiteて聞いてポリタンク思い出した奴は年齢書け
iOSアプリ 開発者の雑談スレ48 [スパムアーツ]
VMware Fusion for Mac Part 36
【永遠の】 iCab 011 【ベータ】
あえてAndroidケータイを選ぶMacユーザーの会
[S] Scrivenerで物書きを楽しもう　- 4 -
使えるdefaultsを書き込め -int 2
[SDK]iPhoneアプリ開発初心者質問箱49[touch][iPad]
【まあ】敢えてMacで3DCG【そう言わず】Part 4
[S] Scrivenerで物書きを楽しもう　- 4 -

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


1 ：2013/11/14 〜 最終レス ：2017/04/09
[前スレ]
Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7
http://anago.2ch.sc/test/read.cgi/mac/1194073058/
Mac関連の英文記事や英文マニュアルなどを、暇な人たちが翻訳するスレッド第８弾です。
「この英文の内容を知りたいんだけど、自動翻訳じゃ意味がｻﾊﾟｰﾘ」という場合に活用してください。
＜＜依頼者へのお願い＞＞
◎翻訳する人はあくまでボランティアです。以下の点にご注意下さい。
・訳文の二次利用はご法度です。
・ご自身のサイトの翻訳はご遠慮下さい。
・あまり長すぎる文章を依頼しないように。
・翻訳してくれる人への感謝の気持ちをお忘れなく。
［過去スレ］
Mac関連テキストをすごい勢いで翻訳するスレッド
http://pc.2ch.sc/mac/kako/1020/10204/1020487234.html
Mac関連ネタを凄い勢いで翻訳スレ2
http://pc.2ch.sc/test/read.cgi/mac/1035938842/
Mac関連ネタを凄い勢いで翻訳スレ3冊目
http://pc.2ch.sc/test/read.cgi/mac/1051925818/
Mac関連ネタを凄い勢いで翻訳するスレ・４
http://pc7.2ch.sc/test/read.cgi/mac/1073284076/
Mac関連ネタを凄い勢いで翻訳するスレ5
http://pc7.2ch.sc/test/read.cgi/mac/1116278311/
Mac関連ネタをもの凄い勢いで翻訳するスレ 6
http://pc11.2ch.sc/test/read.cgi/mac/1140671343/
［まとめサイト］
ttp://kb2m.sakura.ne.jp/log/honyaku/index.html

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

3 ：
でですね、
>>前スレ824
おおおおお、すごくよく分かった。拙訳ぜんぜん間違ってましたね。公式ドキュメントも勉強に
なった。とてもありがとう。
事情を知らない人でも分かるように親切な訳注をつけるとしたら、長くなるけどこんな感じだろ
うか：
「レイキャスティングシステムとは、ある点からどこかの方向に光線を投射する、と仮定して、
その光線をさえぎる物体が途中にあるかどうかを検知できるシステムのことで、例えばメタルギア
ソリッドでスネークが「！」されるかどうかを敵キャラの視線にもとづいて判定するみたいな処
理が可能になる。
そしてこの手法を使うと、小型で超高速な物体の当たり判定も処理することができる。超高速で
飛ぶ小さい物体、たとえば銃弾とかは、ちょっとの間に長距離を移動する。ゲームの一般的な描
画間隔は1/60秒だが、その間にも弾は数メートルとか進む。もしその数メートルの間に厚さ50セ
ンチの壁があったら、普通の当たり判定法を使うと弾は壁をすり抜けて飛び続けてしまう。普通
の当たり判定とは、描画フレームごとに弾の位置座標を取得して、その座標が壁の厚みの内側に
存在するかどうかをチェックするようなやり方である。レイキャスティングを使うと、こういう
状況でも弾が壁をすり抜けないよう処理することができる。」
どうでしょう。しかし当たり判定一つとってもゲーム技術の進みっぷりはすごいもんですな。

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

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

5 ：
arsのMavericksレビュー、エネルギー節約の箇所を途中まで翻訳しました。
arstechnica.com/apple/2013/10/os-x-10-9/12/#energy-saving
エネルギー節約
9年前といえば、Appleがデスクトップ機よりもラップトップ機を多く売ることになった最初の年だ。
最近では、ラップトップ機はデスクトップ機の3から4倍売れるのが普通になっている。
奇妙に思えるが、Appleはバッテリーライフを伸ばすことに強くフォーカスしたOS Xをリリースするのを長々と保留していた。

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

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

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

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

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

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

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

13 ：
おお、続きが。

14 ：
アイドル時間が大量にあるのが分かるだろうか？ しかしこれは実情と異なる。
実際のCPUは動作状態からアイドル状態に即座に移行できない。遷移時間が存在するのだ。
それは長くはなく、またその遅れはこれまでの技術改良により低減され続けているが、ゼロにはなっていない。
実際には、現在のIntel CPUは10〜15マイクロ秒でクロックゲートに従って遷移し、
電力が完全に落とされているコアの状態をリストアするのに数千マイクロ秒かかる。

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

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

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

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

19 ：
メールでのプログレスバーを考えてみよう。バックグラウンドでメールを受信してアップデートする。
もしメールが前面にいなかったら、プログレスバーはおそらく1秒に10回もアップデートする必要はない。
たぶん1秒に1回で十分だ。
あるいは、完全に隠れているWebブラウザのウインドウでアニメーションを再生することを考えてみよう。
そのアニメーションを再生させる必要はまったくない。
経験則が浮かび上がる：
ユーザーにとって、直接的でもなく将来においても利益がないなら、頻度を下げるか；可能であれば、まったく実行しない。

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

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

22 ：
サンドボックスやGrand Central Dispatchのような新技術とは異なり、
Appleはサードパーティの開発者がアプリケーションをApp Nap対応にする時間を与えていない。
Mavericksで動作するアプリケーションはデフォルトでApp Napに対応している。
アクティビティモニタの新しいエネルギータブはプロセスのエネルギー消費を表示し、そこにApp Napの表示も含まれている。
（画像）
アプリケーションがNap状態のとき、そのCPUとI/Oの優先度は低くなり、アプリケーションがあまり作業をしなくなる。
しかし前の章によれば、作業が連続した塊にされているはずだが？

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

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

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

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

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

28 ：
ここから、arstechnica.com/apple/2013/10/os-x-10-9/14/ の翻訳です。
App Nap ポリシー
翻って、Mavericksではアプリケーションリソースに飢えてしまうことでMacが遅く感じられるのではと心配されるかもしれない。
しかしApp NapそしてMavericksのゴールを思い出そう、バッテリーライフを延ばすだけでなく、レスポンスも改善することだ。
App Napをエネルギー守銭奴としてみるよりも、エネルギーを保護するためプロセスを調節する守護者であり、
多くのシステムリソースに可能な限りアクセスすることを保証するものとしてみよう。
成功か失敗かは、アプリケーションがNapするその時と場合はどうなのかという問いにつながる。

29 ：
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がアプリケーションに与える影響をより細かくコントロールできるはずだ。

30 ：
CocoaアプリケーションはデフォルトでApp Nap対応とされていて、 望まない場合は意図して切にしないといけない。
前述したプライベートなシステムコールの存在は、それ以外の普通のGUI Cocoaアプリケーションでない類いのものは
App Nap非対応であることを意味する。
事実、"前面ではない" Cocoaアプリケーション
(例えば、ドックにアイコンが現れないもの― LSBackgroundOnly か LSUIElement Info.plist keyを見てみるとよい）
もまた、App Nap対応ではない。
（バックグラウンドアプリケーション用の、別のエネルギー節約戦略が存在する；あとで説明しよう）

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

32 ：
WWDCでのApp Napデモのひとつに、古いxeyesアプリケーションのCocoa実装があった。
シンプルな目玉のペアがカーソルを凝視しつづけるのは電力を食うように感じるが、
こういう無害なアプリケーションは最終的にシステムリソースの公正な共有よりも多くのリソースを使ってしまう。
Xeyesは自身が前面アプリケーションでない時もカーソルを定期的に追跡せねばならず、
マウスの移動に反応してインターフェイスを継続的に再描画しなければならない。
確かに、アクティビティモニタの新しいエネルギー影響―アプリケーションの電力使用を統合表示したもの―によれば、
目玉によるマウス追跡は驚くほど過酷だ。
しかしApp Napのデフォルトのヒューリスティックでは、別のウインドウを目玉の上にドラッグして見えなくすると、
完全にぼやけて、最後にはアプリケーションがNap状態になりエネルギー影響はゼロになる。

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

34 ：
エネルギーのベストプラクティス
説明した xeyes デモアプリケーションの実装例は、マウスの位置を定期的に集計しそれに合わせて目玉のグラフィックを更新している。
スムーズなアニメーションのために、集計は1秒間に20〜30回行う必要がある。
不幸にも、集計はこのタスクを完遂するのに唯一効果的な方法だ。
カーソルがまったく動いていないときも、アプリケーションはマウスの位置確認を繰り返している―
もし開発者が以前の状態を保持していなければ毎回目玉を再描画する。

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

36 ：
OS X はエネルギー効率により長けた global event monitoring を提供する。
（これはMavericksの新機能ではない） OSが既にカーソルを追跡している；個々のアプリケーションがそれをやる必要はない。
アプリケーションは単にカーソル位置についての興味を表明すればよく、あとはOSが位置変更を知らせてくれる。集計は必要ない。
これは、カーソルが動いていなかったりウインドウが隠れていたりアプリケーションがNap状態でないときでも、
xeyesのCPU使用をゼロ近くに下げることができるということだ。
理想的な形だ：アプリケーションは普段何もせず、CPU使用は限りなくゼロに近づく。
これを達成するために、Appleはすべての集計作業を非推奨にした。
システム上の注目すべきイベントはそれを要求するアプリケーションに通達される：
FSEventsはファイルシステムの変更を；
GCD dispatch sourcesはファイルとネットワークI/O、プロセス生成と消滅、シグナルを；
セマフォとロックはプロセスの同期を。

37 ：
アプリケーションが集計作業から免れたら、さらなる効率化のために他に何があるかを考えるときがくる。
ここから、arstechnica.com/apple/2013/10/os-x-10-9/15/ の翻訳です。
App Nap API
見てきたように、App Napヒューリスティックは
ユーザーに有用なフィードバックを返さないアプリを特定してエネルギー制限ポリシーを適用する。
しかしこのプロセスは不完全であり、もっと重要なことに、調整されていないアプリケーションはポリシーの適用を認識することができない。
App Napが適用される（実際には約10秒かかる）前に、アプリケーションはApp Nap APIを使ってそれを自分の手の内にできる。

38 ：
可視性
最初のAPIセットは、アプリケーションが閉鎖されて自身で行動する時にそれを発見できるようにする。
アプリケーションはウインドウが見えてないときに閉鎖されたと考えられる。
（メニューバーも内部的にはウインドウだが、アプリケーションが作ったステータスバーアイコンを含んでいない限りカウントされない）
ウインドウの枠が見えていたら、アプリケーションが表示されていると考えられる。
ドックにしまわれたウインドウは表示されているとみなされない。
アプリケーションの閉鎖状態は bit field で提示される（80年代再び！）。
1つのビットが二つの状態を示す：完全に表示されている、完全に隠れている、の二つ。
Appleは将来このAPIをもっと粒度の高いものにするつもりだろう。

39 ：
独立したウインドウのための閉鎖用APIもある。同じルールが適用される：
ウインドウのどこかが表示されていれば、表示されていると見なされる。
アプリケーション閉鎖用APIとして、ウインドウの可視性がたった1ビットのbit fieldで示される。
ウインドウが隠されてユーザーにとってもはや価値のない重い作業を、ただちに断ち切るためにこれらの可視性APIを使うことができる。
重要なことだが、再表示されるとアプリケーションの動作をすぐに復帰させられる。
エネルギー節約は作業の完全な切断によって実現されるので、
App Napによる自動制限によって、単に作業が遅くなるよりももっと劇的なことになる。
アプリケーションは作業量ゼロの理想状態に近づき、アイドル状態または無視される状態のときはシステムリソースを使わない。

40 ：
タイマーの誤差
CPUアイドル状態からの遷移回数を減らすためにタイマーイベントを融合している様子、
App NapがアプリケーションNap状態のときにタイマーの最大発生回数を制限していること、
変化を特定するためにタイマーが非効率な方法を使って集計を完遂していること、などを見てきた。
しかし、厳格な時間ベースの作業がアプリケーションの中核になっているものもある（リマインダー、RSSリーダー、Twitterクライアント）。
タイマーの使用が適切である状態なら、Maverickは誤差を短縮する経路を提供している。
デフォルトで全てのタイマーに許容されている100ミリ秒の遅れよりも優先されるものだ。

41 ：
アプリケーションが10秒ごとにイベントを起こすタイマーを持っていたら、たぶん1秒かそれ以上の誤差は許容範囲だ。
大きな許容誤差を持つタイマーがもっとシステム上にあり、タイマーイベントが融合されるとより大きな柔軟性を持つようになる。
ミリ秒の精度が必要ない場合、
開発者はより大きな誤差値―タイマーインターバルの10%が推奨されている―を適用するよう強く勧められている。
タイマーはまたApp Napの回数制限から明示的に除外することができる。
そのようなタイマーは稀であるべきで、
一定の応答速度が要求されるハードウェアまたはネットワークを仲介するアプリケーションだけが使うようにとAppleは注意している。
これら "厳密な"タイマーでもミリ秒単位の誤差は許容している。そして、ゼロにしないよう強く戒めている。

42 ：
ユーザーのアクティビティ
新しいユーザーアクティビティAPIは、App Napヒューリスティックを改善する方法を提供する。
作業の本体についてシステムに投げかけることができ、それにはシステムログに投げる解説的な文章や他の診断メッセージが含まれている（例えば、pmset -g assertions コマンドの出力など）
アクティビティの最もよくある型は "user-initiated"で、
直接的なユーザー行動の結果として行われている作業という意味だ（ボタンをクリックした、メニュー項目を選択した）。
アクティビティの別の型は、アクティビティを継続させるためにMacがスリープしないよう明示的に要求する。

43 ：
"background" 型は、それがメンテナンス用作業であり時間に厳密でないアプリケーションであることを意味する。
同じアプリケーション内でユーザーが関わっているタスクに絡まないよう、バックグラウンドタスクはより低いCPUおよびI/O優先度になる。
オプションによってアクティビティ型の意味を改変できる：
"latency-sensitive"オプションは過度な遅延を持てないようにする；
表示を不可能にする、またはシステムスリープを不可能にするオプション；
Sudden Termination や Automatic Termination を不可能にするオプション。

44 ：
これらオプションの多くがすでにある power assertions API の良きフロントエンドになっているが、
ユーザーアクティビティを包括することは開発者がpower assertionの開放を忘れることを少なくし、
Cocoaアプリケーションから使うのがより便利になる。
単一アプリケーションが一度に複数のアクティビティ型を持つことができ、
それら全てを考慮してApp NapはアプリケーションをNapさせるタイミングを決定する。

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

46 ：
しかし恐らく最も重要なのは、Mavericksのバッテリー状態メニューに、
エネルギーを大食いしているアプリケーションをリストアップする "殿堂入り" セクションが含まれたことだ。
画像：The battery status menu now calls out energy-hogging applications.
アプリケーションがエネルギーの一気消費で遅くなってしまいユーザーからメールが飛んできて開発者が困惑するさまが想像できる。
アプリケーションによっては作業を行うためにエネルギーを大食いする必要がある。

47 ：
おそらく、Appleは（自身のアプリが）殿堂入りするのを避けようとするだろうが、避けられるものではないだろう。
スクリーンショットのように、Apple自身のアプリケーションがメニューに現れる事態もあっさり起こる。
アクティビティモニタのメニューからアプリケーションを選択して、エネルギータブに切り替えると、
有罪アプリケーションがハイライトされる。
この機能が必然的にカスタマーサポートを騒々しくさせるにも関わらず、これはMavericksの最も重要なエネルギー節約機能のひとつであろう。
Appleはここ数年、OS Xの効果的なリソース使用という教義を説き続けている。
ほんのわずか効率的でないアイドル状態を持つアプリケーションを総計することにより露になる静かで寄生的なエネルギーロスというのは、
開発者のモチベーションになりにくい。

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

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

50 ：
大変乙
次回も期待

51 ：
偽の神さま激しく乙であります。
順番が変なんですが、圧縮メモリの項を訳してみました。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とディスクとの間でデータを行ったり来たりさせる作業でシステムがいっぱいい
っぱいになってしまうのだ。
（つづく）

52 ：
（つづき）
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の方向性に沿った変化が若干うかがえはするけれども、現時
点でまだスワップファイルは使われている。しかし、やはり使用は避けたほうがよっ
ぽどいい。
（つづく）

53 ：
（つづき）
パフォーマンスだけの問題ではない。パフォーマンスとエネルギー消費効率は不可分
の関係にある。「居眠り競争」
（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の量を減らすことで
ある。
（つづく）

54 ：
（つづき）
長年の間、OS Xは各アプリケーションが自分の確保したメモリ領域を「破棄可能
（purgeable）」と指定できるAPIを提供している。例えば、アプリケーションはリソース
消費の多い処理の結果を破棄可能なメモリ領域にキャッシュしておくことができる。そして
OSは、追加のRAMを必要とした時、そのキャッシュ領域を他の目的のために自由に使うこ
とができる。キャッシュを作成したアプリケーションがその情報を再び必要とした時は、も
う一度計算し直すだけのことだ。
せっかくのメモリ領域にあえて「破棄可能」と印をつけたがるアプリケーション開発者な
ど、いるわけがないと思われるかもしれない。なんだって自分が確保したメモリ領域を進ん
でOSに返してやらなきゃならんのか。だが、OSの言うことは絶対だ。奴は有無をいわさず
RAMを取り返す。破棄可能なメモリ領域を指定することで、アプリ開発者はそういう時にど
のメモリ領域から先に返していくかを選ぶことができるのだ。
（つづく）

55 ：
（つづき）
それでもまだRAMが足りなければ、OS自身のキャッシュや破棄可能メモリ領域が使われ
る。また、メモリマップトファイル
（ttp://ja.wikipedia.org/wiki/メモリマップトファイル）
はディスク上だけの存在に戻せばいい。ファイルシステムのデータ・メタデータのメモリキ
ャッシュも消去できる。
全てのアプリケーションが搾り取られ、全てのOSキャッシュが破棄された後でもなおRAM
の需要が満たされない時、これまでのOS Xはスワップファイルを使いはじめる他に道がなか
った。
Mavericksでは、スワップという最後の手段の前に、もう一つの方法が用意された。圧縮メ
モリである。Mavericksは、メモリ中の最も使用履歴が古いデータを探し、通常、約半分の
量に圧縮する。ご覧あれ、さらなる空きメモリである。
（つづく）

56 ：
（つづき）
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バイトを守ってい
る。）
（つづく）

57 ：
（つづき）
この状態でさらに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に詰め込むま
で、スワップに触りもしない。
（つづく）

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

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

60 ：
ほ

61 ：
支援

62 ：
紫煙

63 ：
あげ

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

65 ：
>64
シラクサさん、本当はサーキュースって発音するみたいよ。
とりあえずSwiftの部分を訳し始めたので書き込んでみます。
ttp://arstechnica.com/apple/2014/10/os-x-10-10/21/#swift
Swift
ソフトウェア開発というものは常に移り変わっていくもので、一箇所にとどまるということがな
い。ただ、この業界全体を引っ張っていくただ一つの方向性があるとすれば、それは、抽象度の
上昇である。もちろんその歩みは一直線ではなく、停滞期、大飛躍、そして数多くの挫折があっ
た。しかし長期的な傾向は明白だ。
最初期のプログラムは、マシン語で書かれていた。マシン語とは、たいてい2進数か16進数で表
現された数値の羅列である。ここから抽象度のハシゴを一段上がったのが、素の数字ではなく、
文字記号を使ってデータと命令を表現したアセンブリ言語である。次の段階、PascalやCのよう
な言語は、それぞれに固有の命令セットを持つCPU間の違いを吸収し、ハードウェアに依存し
ないインターフェースをプログラマに提供した。そして、そこからさらに進んだJavaやC#のよ
うな言語になると、メモリに直接アクセスするという形をとらずにプログラムが書けるようにな
った。

66 ：
（承前）
アップルの歴史は、ほぼこのようなプログラム言語の歴史とかぶっている。初代マッキントッシュ
はその後の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がまた同じ愚を犯し、他企業に遅れをとるのではないかと警告し
たが、その時に念頭にあったのは、この惰性だ。

67 ：
（承前）
AppleがようやくモダンなOSを手に入れるためには、NeXTの買収とスティーブ・ジョブズの
復帰を待たねばならなかった。では、AppleをObjective-Cの先へ進ませるには、いったい何が
必要なのだろうか。もしAppleが次の一手をすぐに考え始めなければ、2010年にはCoplandの
ような悲劇が待っているのではないかと私は憂慮した。その頃には、全ての競合相手がプログ
ラム言語の抽象度を高めてくるだろうと想定したからだ。
2010年は始まり、そして去った。低レベル言語の使用により、競合するスマートフォン・メー
カーよりもパフォーマンス上優位に立ってモバイル市場で成功していたこともあり、Appleは
依然好調を維持していた。私はタイムライン上の慎重派諸氏から憂慮が杞憂に終わった件を責
められた。それはまさにおっしゃる通りだったのだけれども、それでも私は問題が残っている
と主張し続けた。アップルは、何かをしなければならなかったのだ。
この意見はApple内外のMac、iOSデベロッパーの多くから激しく反対された。当然である。
しかし、Apple社のある一人の重要人物が、最先端をさらに革新する機会を見出し、それをも
のにした。2010年の7月、奇しくも私の「Copeland 2010 再び」という記事が公開された一ヶ
月後、AppleのLLVMコンパイラの開発者であり、当時Apple社開発ツールグループのシニアマ
ネージャとなっていたクリス・ラトナーが、新しいプログラム言語の開発にひそかに着手した
のである。
（とりあえずここまで。続きは時間ができ次第）

68 ：
>>67
乙です
ありがとう

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

70 ：
（承前）
４年後、Apple開発ツール部門主任となっていたラトナーは、2014年WWDCの基調演説に登
壇。OS XとiOSのための新言語を発表し、集まった数千人の開発者を驚愕させた。驚いたの
は、多くのApple社員も同様だったろう。これがSwiftである。
良くできた推理小説の結末と同じく、Swiftの発表は過去の事件を新たな光で照らし直すことに
なった。プロパティのシンセサイズ (Synthesized properties)、ドット記法 (dot syntax)、ブ
ロック (blocks)、参照カウントの自動化 (automatic reference counting = ARC)、そしてコレ
クション定数 (collection literals)。Objective-Cに長年にわたって順次追加されていったこれ
らの機能は、我々に気づかれることなく、水面下で形成されつつあった新たな存在の輪郭をな
ぞっていたのである。特にARCなどは単なる見た目の問題を大幅に超えていた。当時Swiftが
存在していたとしたら、そのまま採用できたような機能だったからだ。

71 ：
（承前）
ここでSwistの文法と機能を網羅するつもりはない。Appleが無料で ”The Swift Programming
Language” というe-bookを公開しており、そこで事細かに説明されているからだ。公表以
降、Swiftは頻繁に変更が加えられている。e-bookもすでに４度にわたって改定されている。
Appleはアプリケーションの実行バイナリの互換性についてはある程度のガイドラインを示し
ている一方、Swiftの進化に伴ってソースコードは互換性を維持しない旨明言している。
Swiftの最も重要な点は、”The Swift Programming Language” の第１章に書かれている。
Swiftが目指すのは「史上初めてスクリプト言語のような豊かな表現力と楽しさを備えた、業務
開発に耐えるプログラム言語であり、”hello, world” からOS全体までを扱えるよう設計されて
いる。」
この理念はあまりに壮大、というかむしろバカげているほどなので、読者諸氏はまともに取り
合わないか、あるいは黙殺してしまうかもしれない。しかし、これこそがSwiftの構想を理解す
る鍵なのである。
（やっと前置き終わり。そして吾輩はここで寝るのである）

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

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

74 ：
>>68
>>73
どもです。
（承前）
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 }
////////////////////////////////////////////////////////////

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

76 ：
（承前）
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/

77 ：
（承前）
ここまでくれば、高級言語のプログラマもなじみやすく感じるに違いない。しかし話はまだ続
く。豊かな機能を備えていながら、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)

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

79 ：
いやはや、まじ乙です。

80 ：
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/

81 ：
（承前）
高級言語を安全で使いやすくしている機能は、それゆえに速度の低下を招いてしまうものなの
である。偶然にも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を生成することはできない。

82 ：
（承前）
変数に格納されている値の型がソースのコンパイル時に決定できないのであれば、それはプロ
グラムの実行時に決定しなければならない。さらに、もし２変数のいずれかに数値が入ってい
ない、あるいは両者にそれぞれ違う種類の数値が入っている場合には、二つを適切な型に変換
するための処理を追加で実行しないといけない。
JavaScripotでは、+という単純な演算子でさえ意味が状況依存的だ。もし a + b という式でa
が文字列であれば、+演算子は数値の加算ではなく、文字列の結合という処理を実行するのが
正しい。
大事なのは、こうした判断がプログラムの実行中に行われるということだ。JavaScriptエンジ
ンは、コンパイル時に生成されたADD命令を単純に実行するのではない。まずはそもそも何を
すべきなのかを判断するためだけに、数十、あるいは数百の命令を実行しなければいけないの
だ。
もし二つの整数値を加算するために数十のCPUサイクルを消費するようでは、Swiftが「シス
テム開発のための業務に耐える言語」になることなど到底不可能である。この問題を解決する
には、CやObjective-Cのように、Swiftのすべての変数、関数の引数、そして戻り値の型を明
示的に宣言させるのが最良の方法だ。そうすればコンパイラは a + b というコードが何をして
いるのか、そしてどの意味で+演算子を使えばいいのかが分かる。

83 ：
（承前）
確かにそれはそうなのだが、これまで示してきた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
////////////////////////////////////////////////////////////

84 ：
（承前）
しかしここからが絶妙なのだ。先に述べたように、これらの基本的な型は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

85 ：
（承前）
ここで先の a + b の例に戻る。整数値をもつ２つの変数があり、それが+演算子で結ばれてい
ると仮定しよう。Swiftのコンパイラは、標準ライブラリをコンパイルするまで、この２変数に
ついて何も分からない。このコードを、２整数を加算するCのコードのように高速にすること
など可能なのだろうか。
////////////////////////////////////////////////////////////
func add(a : Int, b : Int) -> Int {
return a + b
}
////////////////////////////////////////////////////////////

86 ：
（承前）
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
///////////////////////////////////////////////////////////////////////

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

88 ：
（承前）
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

89 ：
（承前）
下の図は、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

90 ：
（昨日は連続書き込み制限を食らったので全部アップできませんでしたが、ここまで翻訳して
あったのでした。）
（あと、>>83の型推論に関するWikipediaへのリンクが間違っていました。以下が正しいで
す。）
http://ja.wikipedia.org/wiki/型推論
（反応をくれた>>79さんをはじめ、読んでくれている人どうもありがとう。訳が変、あるいはこうすればもっと分かりやすい、ということがあればぜひ教えてください。）
（では、おやすみなさい）

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

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

93 ：
（承前）
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
///////////////////////////////////////////////////////////////////////

94 ：
（承前）
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標準ライブラリに収められている通り
の、「原典に忠実な※」コードだ。

95 ：
（承前）
///////////////////////////////////////////////////////////////////////
// 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

96 ：
（承前）
// 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コードにインライン変換などの処理が適用され
た、オプティマイザが最適化を加える前の状態」を比喩的に表現したものと解釈したが、自信
なし。

97 ：
（承前）
コードが少しややこしくなってきたが、もうすぐ核心部に入るので、どうか付いてきてほし
い。注目は、上のコードで何回も出てくる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

98 ：
（承前）
そして、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.+関数に付けられていたものだが、気づかれただろうか。
（また連続投稿で弾かれてます。仕方ないのでおやすみなさい。>>91さん>>92さんコメント
ありがとう）

99 ：
（承前）
ここで、ようやくすべてのピースが出揃った。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属性を使って特定の関数を自動でインライン展開するよう指示したりもしている。

100 ：
（承前）
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標準ライブラリがその務めをしっかり果たせば、そ
れが高速化と効率化のためにどのようなテクニックを使っているかを開発者はまったく意識しないですむだろう。


100〜のスレッドの続きを読む
Mac OS 用エミュレータ Ver.2.3 beta [EMU]
Pixelmator Part 3.3
Macの動画管理
【CSシリーズ総合】Adobe Creative Suite 53
結局、何のためにMacを使うのか？
シェアウェアのプロモーション情報v.12
WWDC2019
Mac OS X初心者質問用スレ 28.2
SnowLeopard以降のOSって本当に必要だったかぁ？
誰か、いらなくなったMacを下さい【8台目】
--------------------
【曲名】あの曲なんて曲だっけ？26曲目【質問】
リトルドラゴンズカフェとかいう名前は違うけど牧場物語最新作を任豚がだが買わぬをし爆死させる
眞子　美智子上皇后が不在のスキに、小室との婚約発表を強行か　『国民無視　徹底抗戦』
[中国ドラマ]女医明妃伝〜雪の日の誓い〜 第一集[チャンネル銀河][衛星劇場]
【研究】「見えない銀河」３９個発見　東京大などの研究チーム「宇宙は思い描いていたよりも銀河で混み合っている可能性がある」
WindowsXPを使い続けるよ85
興行収入を見守るスレ3367
2年前に「中井りかは指原より売れる」と思ってた奴
【チョンすら嫌がる】国籍を捨てる朝鮮人が急増、移民先は米国や日本が人気【ヘル朝鮮】
【バーチャル】hololiveアンチスレ#6797【youtuber】
グリキュー12
とにかく掲示板に書きこみが欲しいなら・・
【patagonia】パタゴニア【街着】part 110
テレ朝•玉川徹、政府の新型コロナ対策バッサリ「医療崩壊です」「ネトウヨの方々、出番です」★２
山口県って
柔道「世界ランキング制」について。
プレミアムステイタス Part.2
【ロマサガ1】ロマンシングサガ1 part18【SFC/WSC】
【正論】経済学者「ごめん、パソナや電通が政府の事業に関わってたら何が問題なの？」 [913590994]
LCレンディング★４
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼