スマートフォンが搭載しているメモリ容量は非常に速いペースで増加しています。
下記ページに日本で発売された端末のスペックを集めています。
・端末全リスト: 日本で発売されたスマートフォン・タブレット全リスト
ざっと眺めただけでもだいたいこんな感じ↓でしょうか。
2008 年 128MB 2009 年 128MB〜256MB 2010 年 256MB〜512MB 2011 年 512MB〜1GB 2012 年 1GB〜2GB 2013 年 1/2GB〜?
特に Android デバイスで容量増加が著しいことがわかります。
このペースが今後も続くと考えるならば、来年には 32bit プロセッサの
壁にぶつかることになります。
RAM 容量が必要になる原因の一つとして画面の高解像度化が考えられます。
こちらも RAM 増量に負けないペースで進化してきました。
2008 年 128MB 480x320 x1.0 2009 年 128MB〜256MB 480x320〜800x480 x2.5 2010 年 256MB〜512MB 854x480〜1024x768 x5.12 2011 年 512MB〜1GB 854x480〜1280x800 x6.67 2012 年 1GB〜2GB 854x480〜2560x1600 x26.67 2013 年 1/2GB〜? 1280x720〜?
高解像度化に伴いアプリケーションで必要な描画リソース量も増加します。
解像度が高いと CPU 描画が間に合わないので、GPU のサポートも必須となります。
描画やレイヤーの合成など OS が管理する GPU リソースも大幅に
増えているのではないかと考えられます。
それ以外にも多数要因があると思いますが、
プロセッサ全体の性能向上とそれに合わせた要求から、
64bit 化は自然な流れだといえるでしょう。
しかしながら、今一番 RAM 容量が切迫しているのは Android の方です。
iOS は Android のおよそ半分の RAM 容量で動作しているため、
iPhone 5s の A7 が先陣を切ったのはかなり意外だと思いました。
64bit 化のメリットとしてアドレス空間の拡張が挙げられますが、
他にも様々なメリットがあります。
特に 64bit mode は互換性の枷から逃れるための大きなチャンスであり、
64bit 化においてはさまざまなアーキテクチャの変更が行われているようです。
ひとつは命令セットやレジスタなどのハードウエア的なアーキテクチャの
変更で、もうひとつはソフトウエア的な取り決めを再設計可能なことです。
全く使われないけど互換性のために残っている機能とか、
設計が古く都合が悪くなっていた仕様などを切り捨てることが出来ます。
(もちろん 32bit 動作 mode では互換性が保たれます)
ARM はロードストア型の RISC プロセッサですが、ひとつの
インストラクションに複数の機能が盛り込まれた多機能な命令体系でした。
例えば命令フィールドには Condition Code が含まれており、条件付き
実行が可能だったり、ソースオペランドに Shifter が組み込まれているなど
かなり独特です。
AArch64 では全く異なる別の命令セットになっています。
よりシンプルで実用的な設計になったと言われていますが、見たところ
便利そうな少々変わった機能も豊富で、十分 ARM らしいと感じました。
コンパイラの出力コードを比べると、関数によっては 64bit の方が命令数が
減ってコンパクトになっていることに気が付きます。
・Nexus 7 の Ubuntu で ARM の abi softfp と hard-float を比べる
上記のように ARMv7 では互換性の問題から softfp (soft-float) が
使われることがありました。
浮動小数点値も関数入出力では一旦整数レジスタを経由しており無駄が発生します。
AArch64 (64bit) ではこのような配慮が不要なので最初から hard-float 相当
となっているようです。
// AArch64 __Z5func3fff: ; @_Z5func3fff ; BB#0: fadd s0, s0, s1 fsub s0, s0, s2 ret lr __Z5func419__simd128_float32_tS_: ; @_Z5func419__simd128_float32_tS_ ; BB#0: fmul.4s v1, v0, v1 fadd.4s v0, v1, v0 ret lr
// AArch32 __Z5func3fff: @ @_Z5func3fff @ BB#0: vmov d18, r1, r1 vmov d20, r0, r0 vmov d16, r2, r2 vadd.f32 d18, d20, d18 vsub.f32 d0, d18, d16 vmov r0, s0 bx lr __Z5func419__simd128_float32_tS_: @ @_Z5func419__simd128_float32_tS_ @ BB#0: vmov d17, r2, r3 vmov d16, r0, r1 mov r0, sp vld1.32 {d18, d19}, [r0] vmul.f32 q9, q8, q9 vadd.f32 q8, q9, q8 vmov r0, r1, d16 vmov r2, r3, d17 bx lr
64bit 化が直接的な理由ではありませんが、
ABI やスタックフレームの改良ができることも実パフォーマンスに
影響を与えているのではないかと思います。
実際に Windows の x86/x64 でも、両方使っていると
同じ CPU 上でも明らかに 64bit の方が速いことに気が付きます。
64bit が苦手と言われていた Core 2 でもきちんと効果がでていました。
x64 でレジスタ数が倍増したことが一番の要因かもしれませんが、
ABI のようにソフトウエアのデザイン面で互換性保たなくて良いことも
大きなメリットになっていると考えられます。
iPhone のメモリ空間にはまだ余裕がありますが、
パフォーマンスの向上や、利用効率を上げて省電力につなげるという
意味でも iPhone 5s の 64bit 化は意味があるように思います。
昨日 ARMv8 AArch64 の浮動小数点演算速度比較のためにコンパイラの
出力コードを調べていたのですが、これ↓が最初なにかわかりませんでした。
orr.16b v5, v1, v1
意味のない or 命令はレジスタ間の move でした。(mov v5,v1)
関連エントリ
・iPhone 5s A7 CPU の浮動小数点演算速度 (2) (AArch64/64bit)
・iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
・Nexus 7 の Ubuntu で ARM の abi softfp と hard-float を比べる
・iPhone 5s の Apple A7 GPU