87726f76bf22892ff6eb07d800b85f90-150x1501

グーグル、アップルを巻き込んだスマホ大変革が2015年に起こる根拠(5/7)

  • このエントリーをはてなブックマークに追加

by [2013年8月20日]

第4回目では高クロック周波数動作以外のプロセッサ性能向上策を扱いました。第5回目では、CPUの64ビット化について考えます。

第1回 「小さくすれば速くて節電に」 はこちら
第2回 「CPU高速化の秘密」 はこちら
第3回 「速度向上の壁」 はこちら
第4回 「 速度が出せないなら物量で解決だ」 はこちら
第6回 「来たるべきプロセッサ」 はこちら
第7回 「未来のプロセッサのもたらすもの」 はこちら

大容量メモリ搭載を可能とする64ビットアーキテクチャ

ここまで、CPUの高速化と低消費電力化を中心に見てきましたが、CPUの改良ではもう一つ重要なトピックがあります。

それは、CPU内部での基本的な計算処理の単位を32ビット長から64ビット長に拡張する、64ビットアーキテクチャの導入です。

64ビットアーキテクチャの採用には、32ビットアーキテクチャと比較して計算の際にCPU内部で用いるレジスタと呼ばれる小容量の高速メモリ1本あたりの容量が倍増し、一度により大きな数が扱える(※正の整数で32ビット=2の32乗=4,294,967,296に対し、64ビット=2の64乗=18,446,744,073,709,551,616という天文学的な規模の数字が扱えます)ため、複雑な計算処理がより高速に行えるだけでなく、扱えるメモリの最大容量、つまりメモリアドレッシングの上限値が大幅に引き上げ可能となる、というメリットがあります。

ARMが公表している20nmプロセスで製造された64ビットアーキテクチャのプロセッサであるCortex-A57と、28nmプロセスで製造された32ビットアーキテクチャのプロセッサであるCortex-A15の性能比較図
Cortex-A57の優位性を示すための資料中で示されたものであるため、一定のバイアスがかかっている可能性や、異なる動作クロックのプロセッサ同士の比較である可能性は考慮する必要があるが、示された全ての項目で大きな性能向上が得られている。

これにより、64ビットアーキテクチャのプロセッサで64ビットアドレッシングを行った場合のメモリ空間の理論上の最大値(※実際に製造された64ビットCPUでは、メモリと接続するアドレス線の本数が64本必要となって回路設計が煩雑になりすぎることや、現状で16エクサバイトものメモリを1基のCPUで扱う事は考えがたいため、扱える実メモリ量はより現実的な値に落とし込んであります)は、2の64乗バイト=16エクサバイト(約172億ギガバイト)という途方もない値となりました。

加えて、つぎはぎに拡張されてきたこれまでの32ビット命令セットとの互換性を維持しつつ、64ビットモードでの動作時には整理・刷新された専用の命令セットが採用できることや、これに合わせてレジスタの構成そのものも大幅拡張が可能となることなどから、プログラムの実行速度についても、既存の32ビットプロセッサに対して一定の優位性が確保できる(※もっとも、過去にはインテルのCore2系プロセッサのように、32ビットモードでは利用できていた特殊な高速動作モードが64ビットモードでは利用できないことから、64ビットモードの方がかえって低速になっていたケースも存在します)ことになります。

なぜ64ビットに移行するのか

元々32ビットアーキテクチャで出発したARM系プロセッサの場合、最初から最大4ギガバイトのメモリ空間を扱えたため、組み込み用途などで使う範囲ではこれで十分すぎるほどで特に問題視されてこなかったのですが、これほどまでにスマートフォンの機能・性能が強化・向上されてくると、また低消費電力のARM系CPUをサーバに利用する動きが出てくると、メモリアドレッシング空間が最大で4ギガバイトまでしか使えない、32ビットアーキテクチャでは不都合な面が目立ってきました。

また、スマートフォンやタブレットに搭載されているARM系のプロセッサの場合、GPUの利用するグラフィックメモリはCPUに接続されたメインメモリの一部を切り分けて利用するのが一般的です。そのため、メインメモリとして2ギガバイトのDRAMを搭載していても、その一部は常にGPUによって占有されていて、メインメモリを全てCPU側で直接扱うことはできません。

筆者が日常的に使用しているHTL21のタスクマネージャ画面
メモリ2ギガバイト搭載のAndroid 4.1環境でも軽いアプリを幾つか動かしただけでもメモリ消費量1.5ギガバイトを超えてしまうことは珍しくない。

現在のAndroid 4.x搭載スマートフォンでは普通に使っていても、軽いアプリを幾つか動作させただけでも1.5ギガバイト~1.7ギガバイト程度のメインメモリを消費していることは珍しくありません。加えて、Android OSそのもののバージョンアップに伴うシステムファイル容量の肥大化(※事実上、新機能の搭載=システムファイル容量の増大を意味しますから、今後Android OSそのもののシステムのスリム化が実現する可能性は低いと考えられます)もありますから、これらだけでも今後1年か2年のうちにメインメモリ容量が2ギガバイトで足りなくなるのは目に見えている状況です。

加えて、近年のGPUの高性能化もメインメモリ容量圧迫の大きな要因となります。

最近のパソコン用グラフィックカードはローエンドのものでもビデオメモリ容量1ギガバイト、上位機種になると2ギガバイトや3ギガバイトのビデオメモリをグラフィックカード上に当たり前のように搭載しています。このことを考慮すれば、それらのグラフィックカード(※1)に搭載されているGPUの機能を一部削減しつつCPUと組み合わせたパソコン用統合プロセッサ(APU)の進化を多少方向性を変えつつも後追いしている現在のスマートフォン/タブレット用統合プロセッサの内蔵GPUが将来このクラスの、つまりギガバイト単位のビデオメモリ容量を要求するようになるのも目に見えています。

一度に扱えるメインメモリ容量が最大4ギガバイトしかない現在の32ビットCPUで、GPUがギガバイト単位のメインメモリをグラフィックメモリとして占有してしまう、というのはほとんど悪い冗談でしかありません。

そこでそうなったときに威力を発揮するのが、4ギガバイトを超えるメモリを一度に扱える64ビットCPUと、これに対応したOSなのです。

  • (※1)グラフィックカード:パソコンに装着し、画面表示機能を追加する拡張カード。画面描画のためのLSIチップや、画面イメージを保持するためのメモリ、そしてディスプレイと接続するための端子などから構成される。
  • パソコンでは既に10年前から普及が始まっていた64ビットCPUとその対応OS

    turbolinux 8 for AMD64
    2003年にリリースされた、x64(AMD64)命令セット対応のプロセッサ向けLinuxディストリビューション。

    パソコン用のx86系CPUでは2003年にAMDのK8アーキテクチャ採用製品群、具体的にはサーバ・ワークステーション用ハイエンドCPUであるOpteronと一般的なパソコン用CPUであるAthlon 64から64ビットアーキテクチャに対応した製品の市販が一般化(※厳密に言えばサーバ用でインテルのIteniumというCPUが先行して市販開始されていたのですが、こちらは既存プロセッサとの命令セットの互換性に乏しく、様々な事情から一般向けには普及しませんでした)していて、OSも遅くとも2009年のWindows 7発売の頃には64ビット版(x64版)が一般化していました(※LinuxだとTurbolinux 8 for AMD64として2003年のK8系プロセッサのデビューと同時に最初の対応ディストリビューションが提供されています)から、64ビット化の波はCPUレベルではパソコンから約10年遅れで、そしてOSレベルでも約5年~10年遅れで、ようやくARMプロセッサに押し寄せてくるのだ、とも言えます。

    ちなみにARMのCortex-A15は40ビットアドレスモードと称して32ビット命令セットのままで扱える物理メモリ空間のサイズを40ビット、つまり1テラバイトまで拡張する特殊な動作モードが提供されているのですが、一般にこの種のアドレス拡張モードは拡張部分で通常の32ビットアプリが動かないといった制約がついていることが一般的で、Cortex-A15の場合もやはりというか、特別な操作を行わないとこの拡張メモリ空間にアクセスできない=実質的に専用アプリやこの空間をサポートする仮想マシンを利用しない限りは役に立たないことが公表されています。

    実は、パソコン用のx86系CPUでも、これと同様に物理アドレス拡張(PAE:Physical Address Extension)といって32ビットOS上で動作しているCPUから最大64ギガバイトの物理メモリにアクセス可能とする技術が存在していて、現在市販されているx86系CPUのほとんどでこの機能がサポートされています。

    にもかかわらず、この機能がほとんど利用されないのは、その拡張されたメモリ空間に通常のアプリがアクセスする手段がなく、一般のユーザーの利用する範囲ではあってもなくても一緒、というかなり悲しい状態だったためです。

    実際、通常のアプリをこの空間に置いて実行させることもできません。そのため、一般的なパソコンではこの機能に対応したRAMディスクドライバを動作させる場合くらいしか、この機能は利用されていません。

    実は64ビットCPUどころか128ビットCPUさえ使われていた家庭用ゲーム機

    Nintendo 64
    任天堂が開発・販売した、MIPS R4300をベースとした64ビットCPUを搭載する家庭用ゲーム機。ただし光学ドライブは無くソフトはROMカートリッジ供給で、メインメモリはわずか4.5メガバイトしか搭載していないため、64ビットアーキテクチャのCPUを採用したメリットは、充分生かされたとは言いがたかった。

    一方、家庭用ゲーム機では任天堂のNintendo 64(MIPS R4300のカスタマイズ品で約93MHz駆動のものを搭載)など(※他にもアタリ JAGUARが存在しましたが、こちらは商業的には完全に失敗に終わりました)で1990年代後半には64ビットアーキテクチャの導入がはじまり、2000年のソニー・コンピュータエンタテインメント(Sony Computer Entertainment Inc.:SCEI)のPlayStation 2では何と128ビットアーキテクチャに基づくCPU(Emotion Engine:MIPS R5900を東芝とソニーが共同で大幅拡張改造したもので、約300MHz駆動。実際にメインメモリとCPUの間は128ビットバスで接続されており、CPUの計算で用いる一時保存用メモリであるレジスタの長さも128ビットであるため、これは間違いなく128ビットアーキテクチャに基づくCPUです)が搭載されていました。

    ただし、これらはいずれも大容量メモリを搭載するためにそうしたアーキテクチャを採用したわけではなく(※それどころかNintendo 64はわずか4.5メガバイト、PlayStation 2でも32メガバイトしかメインメモリが搭載されていません)、当時の技術では動作クロック周波数を大幅に引き上げることが難しかった(※もっとも、PlayStation 2開発当時のインテルやAMDは既に500MHz以上で動作するプロセッサを製品化していました)ために、CPUアーキテクチャの64ビットあるいは128ビット化によって、1クロックで計算できるデータの規模を大きくすることでしか必要な演算処理能力が得られなかったことによるものでした。具体的に言えば、64ビットCPUなら同じ動作クロック周波数で32ビットCPUの2倍、128ビットCPUなら同じく4倍の処理が行えるため、動作クロック周波数を引き上げるのが難しい場合の性能向上手段としてこの種のアーキテクチャ拡張は魅力的だったわけです。

    実際、PlayStation 2の後継機種であるPlayStation 3では3.2GHz、つまりPlayStation 2に搭載されていたEmotion Engineの10倍以上という高い動作クロック周波数が得られたこともあって、その搭載プロセッサであるCell Broadband Engine(※2)は他に幾つか事情もあったものの64ビットアーキテクチャに逆戻りしていて、SCEIは128ビットアーキテクチャに何の未練も無かった(※半導体製造プロセスの制約の中で必要な性能を確保するために仕方なく採用していた)ことがわかります。

    なお、こうしたアーキテクチャの拡張は、必ずしも良いことばかりではありません。例えばWindows 7などの64ビット版は、同程度の内容でも32ビット版と比較して明らかにファイルサイズが大きくなっていて、しかもその動作に必要なメインメモリ容量も32ビット版の1ギガバイトに対して2ギガバイト、と大きくなっています。これは、プログラム本体の命令長が32ビットから64ビットに倍増したことによるもので、データ部分のサイズは変わらずとも、プログラムの命令コード部分のサイズは増大の方向で変化せざるを得ないためです。

    言い換えれば、メインメモリが32ビットアーキテクチャで扱える4ギガバイト以下しか搭載されていないマシンの場合、利用可能なメモリ空間の圧迫を避ける意味で、どうしても64ビットコードで書かれたアプリを使用したい、あるいは将来4ギガバイトを超えるメモリを搭載する予定がある、といった事情が無い限りはわざわざ64ビットCPU対応版OSを使用する必要性は薄い、ということになります。

  • (※2)Cell Broadcast Engine:ソニー、IBM、東芝により開発された、異なるアーキテクチャのCPUコアを混載するヘテロジニアスマルチコアプロセッサ。64ビットのPOWERアーキテクチャ準拠RISCプロセッサコア1基と、8基(実際に動作するのは7基)の独立したSIMDプロセッサコアを搭載。
  • (以下、第6回 「来たるべきプロセッサ」に続く)

    コメントは受け付けていません。

    PageTopへ