・
Android 4.4に入ったARTのソースを見た感想 ～ 組み込みの人。・
Android 4.4 のARTのブートログを見てみた ～ 組み込みの人。・
Android 4.4 Kitkatで新しいランタイムARTと従来のDalvikの動作を比較した動画 ～ Dream Seed
Android 4.4 Kitkatでは内部的に大きく変わる所が有る。
AndroidはDalvik VMがAndroid OSの実行を含め、Androidの全てを牛耳っている。
しかしそこにARTという新しい仮想マシンが登場する。
とは言えまだ「開発者オプション」内に登場しただけにすぎませんが。
仮想マシンを一新するには理由が有ります。
上記の一番上のソースを解析した記事で触れられていますが、まずはこの部分。
Dalvikの中のインタプリタはアセンブラでカリカリにチューニングされ、実行頻度の高い部分を見つけてJITコンパイルを要求するようになっていますが、これにはそのような気配はありません。実行中にバックグランドでコンパイルするということはなさそうです。
当初はアプリの実行速度が問題になったDalvik VMは、2.2ではJITを装備し、
現在ではインタプリタ部分はアセンブラでカリカリにチューニングされ、
これ以上には高速化は難しいという状態のようです。
ここがまずは前提に有ります。
ARTはそういった部分は見られず、当たり前のように普通に組まれているようです。
Dalvik VMはインタプリタが実行頻度の高い部分を見つけては、細切れにJITに渡し、
アプリを実行している裏でコンパイルして実行バイナリ化している模様。
Dalvik VMはアプリの小さな単位で実行コードを部分的に見渡してアプリを
実行しているバックグラウンドでJITがコンパイルしながら実行しています。
一方ARTはアプリの実行コードを、初期に一気にコンパイルしてしまいます。
なので一度目の立ち上げには時間がかかります。しかし二度目以降は予め
コンパイルされた実行コードを実行します。
実行時ではなく、初期に一気にコンパイルをするのは理由が有って、
今流行のLLVM(Low Level Virtual Machine)のコンパイル技術をフル活用する事。
今迄のDalvik VMでは細切れにコンパイルをするので、ベクタライズして
SIMD命令に置き換えたり（昔の86コードで言えば複数のCPU命令を
1つのMMXコードに置き換えると例えれば分かりますでしょうか？）
するには細切れである以上、コード全体への見通しが利きにくく、
不利になります。しかしARTでは一気に全体を見ながらコンパイルをするので、
見通しが利きやすく、細切れでは見つけられない関連性やループまで
見渡せるので最適化には有利です。
例えばループして8bitや16bit単位でメモリにアクセスしている部分を
見つけ、それを64bitのSIMD命令一つに置き換えてループを無くす等と
いった事がDalvikでは難しかったのが、ARTでは検出出来て適用が可能と
なります。ループがSIMDの一命令に置き換われば激しく高速化が期待
できます。これが進行方向に向けたスピードアップ。
LLVMでは並列性も検出がしやすくなり、並列性を見つけたら新たな
スレッドを発行してデュアルコアやクアッドコアのプロセッサでの
コアの稼働率がアップします。
特に非同期実行が可能なスレッドを大量に発行できた場合、同期スレッド
のように「他のスレッドとの同期のサインを待って実行」なんて無駄は
発生しないので、非同期スレッドを検出・発行出来たらマルチコアの
SoCでの実行速度が飛躍的にアップします。
Googleは新端末、特にハイエンドでは、クアッドコアが増えている事に
対してVMをマルチコア向けに最適化しようとしてる事が伺えます。
これは並行性方向に向けたスピードアップです。
組み込みの人。の中の人やその他の方のツイートを適当にズラズラ。
今後はLLVM/Clangの技術を使ったRenderScriptと、LLVMの技術を使った
ARTが合わさって、Androidの高速化が進んでいく事になると思われます。
流れとしてはJITからPreCompileへ、その変化で上記に書いたように強力な
最適化が期待できます。
今時は相当な強者でなければコードの最適化というものは人間の手では行わ
なくなってきていますし、SIMDだけでなく、マルチコア化によって、手で
最適化をするよりもオプティマイザに任せた方が速いという事も十分に有ります。
というか既にそれが主流です。
そうなると、よりARTのようなプリコンパイルに分がある場面も増え、
ターゲットマシンに向けた生の実行コードでの配布でのメリットが
無くなっていきます。
例えばiOSではCPUが64bit化する事で、32bit向けのコードと64bit向けの
コードの両方を配布アプリのコード内に持つことで64bitネイティブ
対応を行いましたが、ARTだと、共通の中間コードからのプリコンパイルで
そのCPUに最適のコードにARTでコンパイルするので、64bitへの最適化が
プリコンパイル時に完了してしまうという訳です。それはアプリ製作者
がアプリを配布するタイミングではなく、アプリをダウンロードして
実行する瞬間に当該CPUへの最適化が行われます。
インテルCPUでもARMv7でもARMv8でも、ART VMのコンパイラがそれぞれの
CPUアーキテクチャにLLVM技術を駆使して最も最適なコードを一つの
Androidアプリの中間コードから吐き出すことによって、アプリ作成者は
既に配布したコードに何ら変更や再配布をする事なく、数えきれない
ぐらい溢れているの種類のCPUを搭載した各種端末への最適化が行われます。
これは既に配布されているアプリを主とした考え方で、Android OSは
OS側がアプリを生かす為に最大限の努力をするOSだと考えられます。
iOSでは逆に、iOSが主として絶対的な存在としてあり、アプリ側が
32bitや64bitの複数のコードを抱き込む事でアプリ側が複数の種類が
有るiOSへの対応をする努力をする事になります。
どちらが優れた方式かという事は論じませんが、技術の進化が激しいの
なら、数多く作られたアプリの修正が都度必要のない方式の方が
アプリ資産を多くリリースしている側は管理が楽だと考えられます。
ARTは正式リリースはまだと思われますが、実はこのARTがAndroid 5.xの
目玉機能になるんじゃないかなという気がしています。
さらに組み込みの人。の中の人が仰っているように、ARTとRenderScriptの
統合も可能性としては有ると思われます。（組み込みの人。の中の人の
意見を読んでいると、単純に技術力が有るだけでなく、将来性を見据える
見識の高さが伺えます）
仮想マシン方式というオーバーヘッドを残した状態の上にOSを組むという、
一見無謀な構成をしてきたAndroidですが、ARTでLLVM技術が実装され、
それが現実的な環境を提供できている事を考えると、今までの欠点が、
一気に長所としてひっくり返る可能性も出てきました。
iOSがコードを複数抱いて配布されている事と、完全に対照的なAndroidとの
静かなコード合戦が2014年のAndroid対iOSの勝負になるような気がしています。
一見大きな変更がなさそうだったAndroid 4.4の隠し玉は、実はほとんど
誰も言及してこなかったART VMだったのかなと私は思っています。
- 関連記事
-
- 2013/11/12(火) 19:50:03|
- 携帯
-
| トラックバック：0
-
| コメント：6
>例えばiOSではCPUが64bit化する事で、32bit向けのコードと64bit向けの
コードの両方を配布アプリのコード内に持つことで64bitネイティブ
対応を行いましたが、ARTだと、共通の中間コードからのプリコンパイルで
そのCPUに最適のコードにARTでコンパイルするので、64bitへの最適化が
プリコンパイル時に完了してしまうという訳です。それはアプリ製作者
がアプリを配布するタイミングではなく、アプリをダウンロードして
実行する瞬間に当該CPUへの最適化が行われるのです。
これってARTの効果じゃなく中間バイナリの採用による効果でしょ
まぁ、インタプリタよりはJITコンパイラ、JITよりはARTによるプリコンパイルのほうが
最適化の効果が上がるのはあっているけど…
Android1.xのインタプリタだってIntelのcore i7とかでもインタプリタをi7に最適化してでうごかせば64bitで動くし、AVXだって使われるはずです
iOSは初めから実行アーキテクチャでバイナリ流通してるので、エミュor互換性が無い限りは原則実行ISA毎にバイナリが必要になってるだけです
- URL |
- 2013/11/13(水) 05:38:13 |
- 姫 #Qgp/yXvw
- [ 編集]
逆に、Androidは配布バイナリが中間バイナリなので、どのCPUを使っても、
DLしてから使うまでの間にどこかの時点で必ずバイナリ変換をしなければならない
というハンデをおっていますね
iOSだとすぐ実行できるバイナリが配布されてるので使う時にはすぐ実行できるという利点もありますね
その代償として、CPUアーキテクチャがころころかわるとアプリのバイナリが増大するという…
- URL |
- 2013/11/13(水) 05:45:46 |
- 姫 #Qgp/yXvw
- [ 編集]
>姫さん
>これってARTの効果じゃなく中間バイナリの採用による効果でしょ
まあそうなんですけど、AndroidとiOSというメジャーなモバイルOS上で言うならばという話です。
ここでその他のOSの事を論じても仕方がないんで。
実装の話として考えるとこの二つに絞るのが分かり易いという事も有りますしね。
>逆に、Androidは配布バイナリが中間バイナリなので、どのCPUを使っても、
>DLしてから使うまでの間にどこかの時点で必ずバイナリ変換をしなければならない
>というハンデをおっていますね
過去のCPUパワーが低かった時代だとバイナリ変換も重い作業でしたが、
どんどんCPUパワーが上がってくると変換コストが無視できる範囲になり、
逆に、取り回しがいいというメリットの方が上回ると考えられます。
実際、例えばWORDやEXCEL上のVBAとか、8bitや16bitの時代には
考えられないような代物でしたが、32bit以上の時代だからこそ、
便利に実用にされているようなもので、ある程度以上のCPUパワーって
余計なコストを消し、七難を隠す効果が有ると思っています。
- URL |
- 2013/11/14(木) 00:04:05 |
- 鈴 #GpEwlVdw
- [ 編集]
CPUパワーの向上は大きいと思います。
Dalvik が頻度の高い部分から細切れコンパイルしていたのは CPU パワーが限られていたので、
全コンパイルしているだけの時間をユーザに待たせる事が出来なかったから。
# 仕組み的にはこちらの方が、より高度ですが。
ART が実行時に全コンパイル出来るようになったのは CPU パワーがそれだけ向上して、ユーザを待たせる時間が許容範囲内になってきたから。
# 余っているコアが有れば、実行時なんて言わずに裏でどんどんコンパイルして、より緻密な最適化が出来るじゃ無いですか。
# もっともバッテリが許せばですが。
ソフトウェアの進歩は、ハードウエアのそれに比べてかなり遅くなるのが常ですので、
アーキテクチャ変化に対応しやすい Android 方式は長い目で見るとより良い結果を出すと思います。
例えるなら
iOS は言われた以上の事はやらない(できない)公務員タイプ。
Android は自分でより良い結果を出そうとするベンチャー起業者タイプ。
おお、やっぱり設計思想とマッチングしますね!!
- URL |
- 2013/11/14(木) 10:45:54 |
- 生ぴーまん #bnistvpo
- [ 編集]
>生ぴーまんさん
そうですね、CPUパワーの向上はAndroidの世界を変えたと思います。
もう一つ大きく影響したなと思うのが、メモリ容量の向上。
JITが搭載された頃は、RAMが256MB～512MBの時代じゃなかったかなと思います。
ここにカーネルからAndroid本体まで全部乗せてアプリを実行することを考えると、
自ずとJITで消費しても許されるメモリが決まってくるという事と、先のCPUのパワーとの
バランス上、JITという選択肢になったんじゃないかなと思います。
プリコンパイル方式だと、大きなアプリではFlashROMに追い出す必要が出てくる
可能性もあり、RAMから比べると極端に速度が遅いFlashROMからの読み出しは
快適な環境を提供できなかった可能性が高いのではと思います。
それと確かに実行中のコードを更に実行結果を受けたり、関連性の解析を裏で
進めてより最適なコンパイルをすることも確かに可能でしょう。しかし実際には
技術的な困難が多い割にはいい結果が出にくいのではないかなと思います。
実行前のプリコンパイルで出来る事は意外と多く、更にその前の段階の
アプリの作者が行うビルドでそれなりの事が行われており、初回起動時には
整理されたコードの変換をするので、技術的な困難を押してまで追加コンパイルを
行う必要性というかメリットは余りないかなという気がします。
公務員とベンチャーの例えは笑いました、確かに(笑)
>ジャホさん
おおっ！
降ってきましたか、更新おめでとうございます。
メモリ容量のレポも有難うございます。
- URL |
- 2013/11/14(木) 23:57:13 |
- 鈴 #GpEwlVdw
- [ 編集]
