87726f76bf22892ff6eb07d800b85f90-150x1501

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

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

by [2013年8月22日]

第5回目ではCPUの64ビット化を扱いました。第6回目では、来たるべきスマホ用CPU像について考えます。

第1回 「小さくすれば速くて節電に」 はこちら
第2回 「CPU高速化の秘密」 はこちら
第3回 「速度向上の壁」 はこちら
第4回 「速度が出せないなら物量で解決だ」 はこちら
第5回 「64ビット化で大容量メモリを」 はこちら
第7回 「未来のプロセッサのもたらすもの」 はこちら

スマホ用CPUの明日

さて、これまで5回にわたって近年のパソコン・タブレット・スマートフォンなどで用いられている技術について説明してきましたが、それでは今後、スマートフォン用CPUはどのような方向に進むのでしょうか?

確定的な64ビットアーキテクチャへの移行

まず、ほぼ確定しているのが、ハイエンド機種での64ビットアーキテクチャへの移行です。

既に現在のスマートフォンで主流のARM系プロセッサの開発元であるARM自身がCortex-A57として64ビットアーキテクチャ(ARM v8)を採用したプロセッサを発表していて、AMDやNVIDIAなどでこの設計に基づくプロセッサの開発・製造も始まっています。

このCortex-A57については、近年需要の増えているARM系プロセッサ搭載低消費電力サーバマシンへの搭載から普及が始まり、この段階では(※恐らくはLTE対応ベースバンドプロセッサ(※1)で最大のシェアを握っているQualcommがSnapdragonシリーズを64ビットアーキテクチャへ移行するまでは)スマートフォンへの採用はごく少数のハイエンド機種に留まると推測できます。

しかし、次世代の14nmプロセスが利用可能となる頃には、64ビットアーキテクチャへの移行で必要となるトランジスタ数が製造プロセスのシュリンクで充分確保できるようになると考えられるため、スマートフォンでもこの系統のアーキテクチャに従う64ビットプロセッサの本格的かつ急速な導入が始まることになるでしょう。

インテルが公開しているAtomプロセッサの初代機種の一つであるAtom 230の情報ページ
シングルコアかつ低速だが、この機種の段階で既に64ビット命令をサポートしていた。

もっとも、実のところをいうと、インテルの現行Atom系プロセッサは低性能ながら第一世代のコアから64ビット命令セットに対応していて(※ただし、一部にサポートされていない機種も存在します)、現在販売されているAtom系プロセッサ搭載のAndroidタブレットやスマートフォンは、Android OSが32ビット命令セットで書かれているために32ビット互換モードで動作させているような状況だったりします。

  • (※1)ベースバンドプロセッサ:音声信号を圧縮伸張することで無線通信を可能とするプロセッサ。信号を変換し各種通信方式に対応する処理も司る。アナログ/デジタルの信号変換の要となるプロセッサであり、相性問題を避ける目的で一度採用された機種および同じメーカーの製品が長期にわたって継続して通信キャリアから搭載指定されるケースが多い。
  • Andorid OSでの64ビット対応時期は意外と早い?

    また、Android OSそのもののベースになっているLinux(※2)でも、2012年12月にリリースされたLinux 3.7からARM v8準拠の64ビットプロセッサが本格的にサポートされるようになっています(※x86系プロセッサでの64ビット拡張、俗に言うx64命令セットのLinuxでのサポートは、これより遥か前、いやそれどころか実際のCPUが出荷される前の2001年には始まっています)。そのため、このあたりの様々な事情を考慮すると、アウトオブオーダー命令実行処理のサポートなどにより大幅な高性能化がアナウンスされている第3世代Atomプロセッサの本格的な市場投入の始まる来年前半に、64ビット版Android OSのリリースが行われても何ら不思議ではありません。

    ちなみに、Android OS対応アプリでも標準のAndroid SDK(※3)を用いて開発され、Java言語で書かれたもの=CPUの機種に依存しないアプリについては、OSに標準搭載されているDalvik仮想マシンが64ビットコードで書き直してあれば、アプリ側で特に何をしなくともある程度まではその恩恵を被ることができます。一方、Android NDK(※4)を使用して開発され、各対応マシンのCPUのネイティブコードにて直に動作するようにコンパイルされたものについては、アプリそのものを開発元で64ビットコードとして再コンパイルしないことにはOSの64ビット化によるメリットは得られません。

    そのため、Android OSが64ビット化しても当分の間は性能が出て欲しいゲームなどの方がかえって速度が出ない、といった状況となってしまう可能性があります。

  • (※2)Linux:1991年にヘルシンキ大学の院生だったリーナス・トーバルズにより開発されたUNIX互換のOS。フリーソフトウェアとして公開され、その後多くのディベロッパーによりボランティアで改良された。学術機関や企業のインターネットサーバなどの用途で広く普及。最近では携帯電話や家電などの組み込み機器のOSとしても使用されている。
  • (※3)Android SDK:パソコンでAndroidのアプリやソフトウェアを開発するのに必要となるツールのパッケージ。コンバイラやデバッガなどの開発ツール、パッケージマネージャ、ドライバ、Androidエミュレータなどがひとまとめになっている。
  • (※4)Android NDK: Androidアプリは通常、Javaで書かれた中間コードによるプログラムの形態で供給され、Dalvik VMという仮想マシン上でこのコードを実際のマシン上での動作に必要なネイティブコードにリアルタイムで変換し、動作する。それゆえ、基本的にAndroidアプリはJava言語で開発する。しかし、このAndroid NDKを使用すれば、Androidアプリのプログラムの一部をCやC++などを用いて記述することで事前にコンパイルされたネイティブなバイナリコードが得られ、中間コードおよびDalvik VMを介さず直接動作の対象となるマシンのCPUで解釈可能なコードが生成可能となる。こうすることで、ターゲットとなるCPUを搭載したマシンでしか動作しないことを代償として、アプリの実行速度の高速化などの効果が得られる。
  • アップルもいずれ64ビット環境へ移行する?

    一方、独自路線を貫くアップルの動向については明らかではありませんが、そもそもiOSの基本となったOS Xの前身であるNeXTSTEP(OPENSTEP)が様々なCPUアーキテクチャに対応していて、既にOS Xがv10.7 Lion以降で64ビットアーキテクチャを基本とするインテル製CPU対応に移行完了しています。

    そのため今後のiOS対応デバイスでも、恐らくここ1年か2年の内に統合プロセッサのARM v8アーキテクチャ準拠64ビットプロセッサへの移行と、iOSそのものの64ビット対応が行われることになるでしょう。

    ハードとソフトの両方を1社で開発しているアップルの場合、ハードの種類を絞れるため、複数のCPUアーキテクチャをサポートするAndroid OSと比較すれば64ビット対応にあたって必要な負担は小さいと考えられます。

    ローエンド端末はOSを問わず当分32ビットにとどまる

    なお、メモリ(LPDDR3 DRAM)のイニシャルコストを考慮すると、CPUもGPUもそこまでの性能を必要としないローエンドの機種のメインメモリについては、OSの種類によらず当分の間32ビットOSで事足りる2ギガバイト以下の搭載に留まると考えられます。

    処理速度などの都合からプロセッサそのものは64ビットアーキテクチャへ移行したとしても、メモリ容量は2ギガバイトに留め、32ビット互換モードで動作させる、というパターンが今後増えるのではないでしょうか。

    進む高クロック化

    半導体製造プロセスのシュリンクが続く限りは、プロセッサの動作クロック周波数引き上げも当然に続くでしょう。

    もちろん、スマートフォンの場合は消費電力および発熱量の低減が重要なため、現在のパソコン用プロセッサのように、最大5GHz駆動可能、という域に達するかどうかはかなり微妙なのですが、最高速度が3GHz台に到達することは、これまでの動作速度向上状況や、ノートパソコン用CPUの動作クロック周波数を見る限りほぼ確定で、よほど何か特別な事情が無い限りは、8nmプロセス実現の段階で4GHzに手が届くか届かないか、といったレベルとなると推測できます。

    進まない多コア化

    これに対し、現状以上のCPUのマルチコア化は進むと考えにくい状況です。

    パソコン用プロセッサでも、一般に市販されている機種で6コア以上のCPUコアを搭載しているものはハイエンドの一部機種に限られており、第3回でも記したように、その内2コア単位で内部ユニットの共用化を行ったAMDの「Bulldozer」及びその改良型の「Steamroller」アーキテクチャ準拠の6コア・8コアCPU(およびその改良製品)は期待されたような性能が出ていない、というのが現状です。

    言い換えれば、数の出るボリュームゾーンの一般的なパソコンでは、ノート・デスクトップを問わず4コアCPUが実質的な標準(※ただし下位機種や省電力重視の機種では現在でも2コアCPU搭載の機種が存在しています)となっており、第4回で触れたPlayStation 4やXbox One(※いずれもAMDの省電力型CPUコアを8基搭載。なお、これは「Bulldozer」や「Steamroller」とは別の1基ずつ完全に独立した設計のCPUコアを搭載しています)のように8コアまでCPUコアを増やす方向性とはなっていません。

    TYAN S8812
    16コアCPUに対応するCPUソケット(Socket G34)を4基備えるサーバ用マザーボードの例。左上に見える3本の8x PCI Expressスロットや全部で32本搭載されているDDR3 DRAM DIMMソケットのサイズからボード全体のサイズが想像できよう。多数のアプリやサービスが同時実行されるサーバの場合、このような重装備かつ特殊構造の巨大マザーボードが利用されることがある。

    ちなみに、こうしたパソコンとは対照的に、消費電力削減の観点から実マシン台数を減らし、仮想マシン上でOSや各種サービスを実行する事が求められ、それゆえに同時に膨大な数の仮想マシン環境を動作させる必要のあるサーバマシンでは、物理的なCPUソケットを4基分実装しそれぞれ16コアのCPUを搭載することで、マシン1台あたり64コアCPU構成とすることも珍しくありません。

    CPUとGPUの融合

    ここまで、CPUそのものの性能向上を取り上げてきたのですが、実は今後のCPUでは、一つのチップに混載されていながら、積極的な共用化、あるいは機能の融合が図られてこなかった、CPUとGPU(※5)の融合によるマシン全体の性能向上が重要視されています。

    GPUの性能向上というのは、基本的に3Dグラフィック表示のために必要となる座標系のベクトル演算をはじめとする各種演算処理機能の強化によって行われてきたのですが、この強力な演算性能を、3Dグラフィック機能をほとんど使わない一般的な使用状況でも有効活用しよう、という考え方が出てきたのです。

    この考え方をGPGPUと呼ぶのですが、それを更に一歩進めて、CPUとGPU相互の間で現在は独立しているメモリ空間(※CPUとGPUを内蔵する現在の統合プロセッサではメインメモリを共用していますが、CPUが占有する空間をGPUがアクセスすることも、その反対にGPUが占有する空間をCPUが直接アクセスすることもできません)を完全に共通化し、互いの情報を制限無く自由にやりとりできるようにしよう、というPlayStation 3のCell Broadband Engineプロセッサが先取りして実行していた(※Cell Broadband Engineは内部的にPowerPC Processor Element(PPE)と呼ばれるOSを動作させるPower PC系のCPUコア1基と、Synergistic Processor Element(SPE)と呼ばれるベクトル演算に特化したPPEとは全く異質な設計のCPUコア8基(実際には7基のみ使用)が内蔵されていて、相互にリソース共有する構造になっています) アイデアが提案されるようになってきました。

    このアイデアに従い、CPUメーカーであると共に有力GPUメーカーであるAMDやARM、それにImagination Technologiesなどが設立したのがHSA FOUNDATIONという業界団体で、現在、参加メーカー各社ではCPU・GPUの双方でこの技術に対応した製品の開発が進められています。ちなみにこのHSA FOUNDATIONには先に挙げた3社の他、Qualcommやサムスン、それにTexas Instrumentsなども参加しているため、ARM系統合プロセッサを開発製造している有力メーカーは、NVIDIA以外全社が参加していることになります。

    現行のCPUコアに手を加えてGPUとの間でメモリなどのリソースを完全共有にするのは、64ビットアーキテクチャへの移行準備が進みつつある現状を考慮すると手戻りが大きく非現実的であるため、この種の技術の本格的な普及は、64ビットアーキテクチャのプロセッサの一般化以降となるでしょう。

  • (※5)GPU(Graphic Process Unit):3Dグラフィックスの表示に必要な計算処理を行う半導体チップ。従来使用されていた3Dグラフィックスの発展系で、担当する処理が多くなっている。
  • 4ギガバイトに達するメモリ

    さて、HSAでCPUとGPUの間で完全共有されるようになるメインメモリですが、これは今後、最初に書いた64ビットアーキテクチャのプロセッサを搭載することを前提条件として、4ギガバイト以上のメモリ搭載が進むでしょう。

    ただし、Android OSでのアプリサイズを考慮すると、いかにAndroid OS本体が肥大化したとしても、スマートフォンの搭載メモリ容量が8ギガバイトに達するのは相当先のこと(※Android OSとは比較にならないほど重装備で複雑なサービスが実行されている、Windows 7/8をOSとするパソコンでさえ、一般的なマシンでのメインメモリの搭載量が8ギガバイトに達したとはまだ言えない状況です)と考えられます。

    ちなみに、メモリの高速化については、キャッシュメモリの搭載、あるいはその増量以外にも、統合プロセッサのパッケージそのものに直にDRAMを搭載(DRAM混載)してしまうことで、間に入る余計な回路をすっ飛ばし、さらに接続バス幅(※6)を大きくしてしまう、という力ずくの手段があるにはあるのですが、これはトランジスタ数の関係で容量に厳しい制約があり、2ギガバイトあるいは4ギガバイトといった大容量メモリを混載にするのは現在の技術では困難です。というのも、DRAMの場合はトランジスタ数が1セルあたり1個で済むわけですが、それでも1ギガバイトのDRAMでトランジスタ数が約86億に達しますから、現在のミドルレンジ以上のスマホで一般的なDRAM 2ギガバイトを統合プロセッサに混載すると、それだけで170億以上、4ギガバイトだと実におよそ350億ものトランジスタが必要となってしまうためです。

    28nmプロセスで製造されている現在のハイエンドGPUでも単独で70億トランジスタ以上を集積したものはほとんどないような状況(※そのクラスのチップですら、大きすぎると考えられています)で、統合プロセッサではCPUとGPUを合わせて30億トランジスタにもなれば大きい部類に入ることを考えれば、DRAM 2ギガバイトを統合プロセッサに混載することの困難さというか無謀さが理解していただけるのではないかと思います。

    Microsoft Xbox One
    マイクロソフトが発表した、次世代家庭用ゲーム機。同時期に発表されたソニー・コンピュータエンタテインメントのPlayStation 4と同様、AMD製のAPUを搭載し、これに8コアのCPUとRADEON系のGPUコアを内蔵する。ただし、思い切って高速なGDDR5 DRAMを8ギガバイト搭載してしまったPlayStation 4とは異なり、廉価だが低速なDDR3 DRAMをメインメモリとして8GB搭載し、これとは別にESRAM(Embedded SRAM)と呼ばれる高速メモリを32MB APUに内蔵して速度不足を補う構造となっている。

    そのため、統合プロセッサにメモリを混載する場合には、CPUコアに内蔵のキャッシュメモリと同様ある程度小容量のSRAMを搭載し、CPUとGPUの間に置かれた共用のワークエリアとして使う、といったパターンが想定され、実際にもXbox Oneではそのような構成となっていると発表されています。

    ちなみにこのXbox Oneの統合プロセッサは50億トランジスタの回路規模であると報じられていますが、6トランジスタ構成のSRAMを32メガバイト搭載しているとすると、ESRAM部分のトランジスタ数は最低でも約16億トランジスタ、つまり全体のおよそ1/3がSRAMに占められてしまっていることになります。

    もっとも、こうしたワークエリアをメインメモリとは別に分散搭載するという考え方は、得られる性能はともかく全てのメモリをCPUとGPUで一元管理し共用しよう、というHSAの考え方とは真っ向から対立するものです。

    もちろん、製造プロセスのシュリンクが十分に進んで、CPU・GPU・大容量DRAMが1チップに問題なく搭載できるようになれば、こうしたメモリの細分化を行わずとも済むわけですが、ギガバイト単位の大容量DRAMの混載は8nmプロセスになっても実現できるかどうか怪しく、またチップ製造上の歩留まりの観点でも難しい問題を抱えることになります。

  • (※6)バス幅:バスとは、コンピュータ内部の伝送経路。このバスにおいて、一度の伝送で、同時に送れるデータ量ga
    「バス幅」。
  • (以下、第7回 「未来のプロセッサのもたらすもの」に続く)

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

    PageTopへ