N9-hero-1200

Nexus 9で始まる64ビットAndroidの時代

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

by [2014年11月05日]

Androidの最新バージョンである『Android 5.0 Lollipop』の初の搭載機種として発表された『Nexus 6』と『Nexus 9』。

これまでならば、これらは単にスマートフォンとタブレットという2つの環境のリファレンス、という立ち位置の違いだけで提供されていて、OSレベルでは差異が生じていなかったのですが、今回は違っていました。

『Nexus 9』の搭載プロセッサのCPUコアがARM v8命令セット準拠となり、64ビットアーキテクチャ化されたため、搭載されるAndroid 5.0の方もそれに合わせて64ビット化されたのです。

そこで今回は、その64ビットアーキテクチャを中心に『Nexus 9』について考えてみたいと思います。

主な仕様

『Nexus 9』の主な仕様は以下のとおりです。

  • OS:Android 5.0
  • チップセット:NVIDIA Tegra K1(Denver 2.3GHzデュアルコア )
  • サイズ:約153.68×228.25×7.95mm
  • 重量:425g(Wi-Fiモデル)・436g(LTEモデル)
  • メインスクリーン
    • 種類:IPS液晶
    • 解像度:2,048×1,536ピクセル(QXGA解像度)
    • 画面サイズ:8.9インチ(対角線長)
    • アスペクト比:4:3
  • 内蔵メモリ
    • RAM:2GB
    • フラッシュメモリ:16GB・32GB
    • 拡張スロット:なし
  • カメラ
    • メインカメラ解像度:8メガピクセル
    • フロントカメラ解像度:1.6メガピクセル
  • Wi-Fi:
    • 対応規格:IEEE 802.11 ac(2×2 MIMO対応)
  • Bluetooth:Ver.4.1
  • NFC対応
  • 電池容量:6,700mAh
  • 防水:なし
  • 防塵:なし
  • 開発製造担当:HTC

一見平凡な“Denver”

この『Nexus 9』最大の特徴、それは何と言ってもNVIDIAが独自開発した64ビットCPUコアである“Denver”をデュアル搭載し、あわせてKeplerと呼ばれるアーキテクチャのGPUコアを搭載する最新の統合プロセッサ、“Tegra K1”の64ビットCPUモデルが搭載されていることに尽きます。

“Denver”はARM v8命令セットに対応し、7つの実行ユニットを内蔵する、スーパースカラー(Superscalar:スーパースケーラとも)CPUコアです。

6ステージ構成のパイプラインを2本組み合わせたスーパースカラープロセッサの動作模式図
プログラムに書かれた命令をどのパイプラインに充填するかを処理するリザベーションステーションと呼ばれる管理ユニットの付加が必要となりますが、こうしてスーパースカラー技術を利用することで、通常のパイプライン技術以上の処理速度向上が期待できます。ただし、メモリの読み書きが本来想定された時系列に従わない(複数のパイプラインを同時実行することから、処理時間の相違により本来の時系列とは異なる並びで計算結果が出力される)場合があるため、このままではハザードの発生可能性が高くなるという難点があります。

スーパースカラーというのは、プログラムに含まれる命令群を忠実に逐次処理するのではなく、多段パイプライン処理(※注1)により一定単位で読み込まれた複数の命令を解釈し、それらを複数のパイプラインに振り分けることでより効率よく命令処理を実行するための技術です。

 ※注1:マイクロプロセッサの命令実行をいくつかの段階に分割し、工場のベルトコンベアーのように段階的かつ逐次的に処理・実行してゆくことで、それぞれの段階で独立した命令を実行できるように工夫した技術のこと。これを用いて命令実行プロセスに含まれる各処理を分割した場合、同じ半導体製造プロセスでもパイプライン化しない場合と比較してより高い動作周波数でCPUコアを動作させられるようになります。

この技術に、多段パイプライン上に並んだ命令群を、プログラムの前後依存関係に影響しない範囲で並べ替えて実行ユニットの動作効率を引き上げるアウト・オブ・オーダー実行や、分岐命令の分岐先を予測し確率の高い方をあらかじめ実行しておくことで処理速度の引き上げや実行ユニットの動作効率引き上げを図る投機的実行、といった技術と組み合わせてプロセッサの処理速度向上を目指す、というのは実のところ古典的手法に属します。

実際、パソコン用CPUでは1993年発表の初代Pentiumで既にこれらの技術は(規模の大小の差こそあれ)実装されていましたし、現在のプロセッサでこれらをサポートしないのは、回路規模をとにかく小さくして低消費電力化を図る必要のあった“Silvermont”世代(※22nmプロセス採用)より前のIntel Atomプロセッサ(※注2)くらいのもので、よほど回路規模が小さいとか消費電力に対する要求が極端に厳しい、といった条件でなければ普通に採用されている技術です。

 ※注2:多段パイプライン技術は採用されている(※16段となっていてむしろ当時パソコン用で一般的だったCore2プロセッサよりも多い)もののイン・オーダー実行とされた結果、命令デコーダ周りの回路規模が大幅縮小されました。

ともあれ、この“Denver”コアはこうした近代的CPUコアの基本的機能を一通りサポートし、しかもARM v8準拠の64ビット命令セットをサポートするCPUコアとして完全新規設計されたわけですが、その割には額面上のスペックは(64ビット命令セット対応であることを除くと)今ひとつ冴えません。

ただ素直に設計するだけであれば、わざわざARM純正のARM v8対応64ビットプロセッサであるCortex-A5xシリーズに代えて大規模な新規開発を行うメリットはありませんから、このプロセッサには表に出ないなにがしかの特別な仕掛けがある、ということになります。

“Denver”の強み

この“Denver”コアの最大の特徴、それは「Dynamic Code Optimization(動的コード最適化)」と呼ばれる、プロセッサ内で利用されるマイクロコードレベルでの動作を最適化し、命令発行数(※注3)を向上させる技術が採用されていることです。

 ※注3:CPU動作の最小単位(サイクル)あたりどれだけの命令を発行できるかを示す値で、これが高いほど効率よくCPUコアが動作していることになり、また同じ時間により多くの仕事ができることになります。

この“Denver”コアではメインメモリ上に128MBの命令コードキャッシュ領域(これを「Optimization Cache(最適化キャッシュ)」と呼びます)を確保し、プログラム上で実行されるARM命令をハードウェアによる命令デコーダで解釈・マイクロコードに変換する際にその動作を最適化した結果を先の「Optimization Cache」へ保存してゆく構造となっています。

こうして保存された変換済み最適化マイクロコード命令は、次にこれに対応する命令が発行された際に命令デコーダを飛ばして直にこの変換済みマイクロコード命令を実行ユニットに送り込んで実行するのに用いられ、命令デコーダ部分での処理にかかる時間を最低限に抑える役割を果たすようになっているのです。
   
こうした工夫の結果、“Denver”コアでは最適化キャッシュに変換済みマイクロコード命令が既に存在している場合、という条件がつきますが瞬間最大風速的に7つの実行ユニット全てを動作させる、つまり命令発行数が最大7に達するという、驚異的な性能を実現しています。

もっとも、これは最適化キャッシュに変換済みコードが存在した場合の話で、そうでない場合、“Denver”コアは命令発行数が2とCortex-A15などよりも低性能となってしまいます。

つまり、この“Denver”コアでは同じ命令コードが繰り返し出現するようなプログラムならば無類の高性能を発揮することが期待できる一方で、プログラム中の命令コードにキャッシュにヒットしないような大きなばらつきが存在した場合、他の競合プロセッサよりも低い性能しか出ない、ということになります。

2度目の挑戦

ここまで読んで、「はて、昔これに似たような仕組みのCPUはなかったかな?」と思われた方も恐らくおられたのではないかと思います。

実はメインメモリの一部を特別なキャッシュとして扱い、命令デコーダで変換したCPUのネイティブコードを保存しておき、2回目からはそれを直に実行することで高速動作を実現する、というこの“Denver”の動的コード最適化技術の仕組みには、前例が存在していたのです。

1990年代後半から2000年代初頭にかけて開発・製品化されたTransmeta(トランスメタ)社のx86互換CPU、“Crusoe”および“Efficeon”がそれです。

この2つのプロセッサは、様々な先進的アイデアを盛り込んだ興味深い設計だったのですが、中でも特に、x86命令をネイティブ命令に変換する命令デコーダそのものについて、メインメモリの専用領域に置かれた“Code Morphing Software(CMS)”と呼ばれるソフトウェアの一部として構成されている(※注4)という、“Denver”以上に野心的な設計を採用していたことがよく知られています。

 ※注4;“Crusoe”も“Efficeon”もネイティブコードレベルではVLIW(Very Long Instruction Word:超長命令語)という1命令で複数の命令をまとめて動作させる、特殊な命令セットを備えた(x86互換でない)CPUとして動作します。つまり、CMSはこのVLIW命令セットを用いて書かれています。

この、x86命令セットでの新規命令の追加にもこのCMSに含まれるソフトウェア命令デコーダのバージョンアップで対応でき、しかも命令デコーダを差し替えれば全く異なるCPUの命令セットにも対応可能、というハードウェアレベルでのエミュレータとでも言うべき柔軟性の非常に高い設計は、その一方で初回命令実行時、つまり“Denver”コアで言う最適化キャッシュに何もコードが存在しない状態では全てのデコード処理を逐一CMSでソフトウェアにより実行するために激烈に速度が遅い、という問題(※注5)を抱えていました。

 ※注5:もっとも、このように命令デコーダをソフトウェア化したことでx86互換CPU開発時の最大の障害となる(実際にAMDをはじめとする互換CPUを開発していた他の各社では再三にわたって問題となってきた)インテルによる特許権訴訟を回避できる、というリスクマネージメント面では無視できないメリットもあったようです。ちなみにこのCMSの考え方を敷衍すれば、Androidで用いられているJavaScriptベースの中間言語コードを直接解釈・実行可能な命令デコーダを作成することも理論上は可能ですが、今回の“Denver”コアでは汎用性の問題もあってか、さすがにそこまでは踏み込んでいません。

“Denver”コアの場合、この部分に競合製品より若干低性能とはいえハードウェアによるARM v8互換命令デコーダを搭載することでこの問題に一定の解決を図っており、Transmetaの失敗の教訓が生かされています。

電力消費と性能のバランスをとるのが難しい命令デコーダ

こうした命令デコーダ周辺はスーパースカラーCPU設計上の核心部とも言える部分で、この部分の出来の良しあしがCPUの性能を決めると言っても過言ではありません。

もっとも、その部分を高性能化すればするほど回路規模が巨大化し、消費電力が指数関数的に増大するという問題があるため、低消費電力での動作が求められるモバイル機器用プロセッサでは、この部分を極端に高性能化するわけにも行きません。

また、各実行ユニットは同等というわけではなく、それぞれ固有の役割を持たされていますから、その固有の機能を連続的に必要とするプログラムの場合、仮に手空きの実行ユニットがあってもそれらでは固有機能を肩代わり実行できないため、命令発行数は小さくなります。

例えばARMのCortex-A15は“Denver”コアよりも1つ多い8つの実行ユニットを内蔵し、相応に高性能な命令デコーダを搭載するスーパースカラーCPUコアですが、それでも命令発行数が最大で3となっており、消費電力とのバランスを取りつつ命令デコーダを改良・強化して命令発行数を増大するのが難しいことが見て取れます。

そのため、瞬間最大風速であろうが何であろうが、条件を満たせば全実行ユニットをフル稼働させられる“Denver”コアの動的コード最適化技術は、その成否が特に注目されるアイデアであるといえます。

パソコン用ローエンドGPUレベルに達していない“Kepler”コアGPU

CPU部分の話が長くなってしまいましたが、このTegra K1ではNVIDIA製統合プロセッサとしては初となる、プログラマブルシェーダーを採用した“Kepler”と呼ばれるGPUコアが搭載されています。

従来のTegra 4系までは旧弊な固定シェーダー内蔵のGPUコアを搭載していましたから、パソコン用としてはTegra K1開発時最新、記事執筆時点でも最新の一つ前となる“Kepler”コアの搭載は、プロペラ機がジェット機になるくらいの飛躍的な技術的進化を意味します。

もっとも、競合他社の製品、具体的にはQualcommのSnapdragonシリーズに内蔵のAdrenoシリーズやARMのMaliシリーズなどといったGPUコアではもう6年も前から(決して高性能とは言えないにせよ)プログラマブルシェーダーが搭載されていましたから、その観点ではようやく周回遅れが解消した、ということになります。

なお、このTegra K1内蔵の“Kepler” コアは192 CUDAコア搭載とのことですから、パソコン用“Kepler” コア搭載GPUカードがローエンドでも384 CUDAコア搭載であることから考えると、クロック周波数やメモリインターフェイスの種類などを無視しても単純に考えて現在のデスクトップパソコン用ローエンドGPUの半分程度の性能しか出ないわけです。

ローエンドデスクトップパソコン並み≠低性能

ただし、この比較についてはTegra K1がプロセッサ全体でも消費電力が最大で5W程度しか許されない非常に低消費電力のプロセッサであり、その電力の枠内で先に紹介した“Denver”コア2つとこの“Kepler”コアを動かさねばならない、というハンデを抱えていることを考慮する必要があります。

むしろ、この電力の枠内でCPU・GPU共に現在のデスクトップパソコンのローエンドモデル並の性能を実現してきたことは大いに評価されるべきで、同世代の競合プロセッサ各種と比較して十分に高速かつ高性能となっていることは、特に強調しておきたいと思います。

これまでであれば長期にわたって基本的には同じ仕様で販売され続ける据え置き型の家庭用ゲーム機、具体的にはPlayStation 3やXbox 360と比較してどの程度の性能か、という議論であった(※しかもAdrenoと同系のXenosというプログラマブルシェーダー内蔵GPUを搭載したXbox 360はともかく、PlayStation 3のGPUは固定シェーダの骨董品みたいな代物だった)のが、ローエンドとは言え現役のデスクトップパソコンと比較してどうか、という話が出来るようになったのですから、実はこれはものすごいことなのです。

無論、競合他社の64ビット命令対応プロセッサでも同様にCPUコアやGPUコアの強化が進んでいて、未だに自社オリジナルの64ビットCPUコアを発表していないQualcomm(※注6)など、まだ見ぬ強敵は潜んでいますし、デスクトップパソコンでもハイエンドモデルからは後ろ姿も見えないほど引き離されているのが実情です。

 ※注6:現時点で発表済みのSnapdragon 410・610・808・810ではARM製の64ビットCPUコアであるCortex-A53・A57がそのまま内蔵されていて、自社開発の64ビットCPUコアは開発中とのアナウンスが出されたままとなっています。

何しろ相手はGPUカードだけでも2GB~8GB程度のメモリを搭載するのが当たり前、CPUに至っては8コア搭載のものまで存在するのですから比較になるならない以前の問題です。

ちなみに現行のPlayStation 4やXbox OneはRADEON HD7850クラスのGPUコアと8つのCPUコアを内蔵した統合プロセッサを搭載し、メインメモリ容量は8GBでその性能がミドルレンジのパソコンに匹敵するレベルに達しているため、このTegra K1はそれらと比較しても見劣りしてしまいます。

これまでの例から考えて、今後はこれら次世代家庭用ゲーム機との性能比較で論じられることになると考えられますが、この世代の据え置き型家庭用ゲーム機では極端に先鋭的な形で性能向上が実現しているため、これに追いつけるまでには恐らく数年の時間は必要となるでしょう。

64ビット化のメリットは何?

さて、ここまで64ビット64ビットと繰り返してきましたが、スマートフォンやタブレットで64ビット命令対応CPUを採用する理由は何でしょうか?

サーバやパソコンであれば、メインメモリを4GB以上積んでもOSで正しく認識し利用できるようになる=これまでの32ビットOS上では扱えなかったような超巨大データが(64ビット命令で書かれた)プログラムで扱えるようになる、というのが最大の理由です。

最近流行の「ビッグデータ」という概念にしても、そうしたパソコンやサーバなどでのCPU・OSの64ビット対応によって超巨大データがオンメモリで高速に処理できるようになったからこそ実用に足るレベルで扱えるようになった、という側面があって、いずれにせよ規模が問題となる場合、64ビット命令セットに対応するCPU・OSへの移行は不可避です。

しかし、過去の記事でも何度か触れてきたように、少なくとも現行のスマートフォンやタブレットなどでは、x86系CPUとWindows 7/8/8.1を搭載しノートパソコン代替で利用されるような一部のハイエンド機種を別にするとメインメモリはメモリチップの消費電力が無視できない程度には大きいこともあって、積んでも3GBというレベルで、少なくともこの面からは無理に急いで64ビット化する必要はないと言えます。

それでは一体何のために64ビット化するんだという話になりますが、結論から言ってしまうと、それは純粋に処理能力の高速化のためだ、ということになります。

ARM系のマルチメディア拡張命令セットであるNEONなどのSIMD命令、昔のスパコン風に言えばベクトル命令だと、専用のレジスタを用いて例えば64ビットのデータ2組、あるいは32ビットのデータ4組、といった形で128ビット分をひとまとめにパックしたデータを行列演算するような処理が多々行われるのですが、そうした命令の専用レジスタとのデータの受け渡しを考えると、レジスタ長が32ビットしかない上にその本数も少ないのが一般的な32ビットプロセッサ(※注7)だとどうしても処理が煩雑になりますし、速度面でも不利です。

 ※注7:ARM系もx86系も、64ビット拡張の際に扱える汎用レジスタの本数を大幅増加させています。

わかりやすく言えば、128ビットサイズの水槽を満たすのに、32ビット命令だと32ビットサイズのバケツで4回水を運ぶ必要があったのが、64ビット命令だと64ビットサイズのバケツ2回で済むということで、同じ時間でより高速に計算処理やデータのやりとりが行えるのです。

もちろん、64ビット化によってCPUコアそのものに必要となるトランジスタ数は大幅に増え、それに伴い消費電力も増加するのですが、仮に64ビットプロセッサの処理能力が仮に32ビットプロセッサの2倍だとすると、極論すれば64ビットプロセッサは同じ処理を行うのに32ビットプロセッサの半分の動作クロック周波数でもかまわないわけです。

一般に半導体はクロック周波数を上げれば上げるほど指数関数的に消費電力が増大しますから、64ビット化によって回路規模が増大することによる消費電力の増加が相殺できるのであれば、また動作させるOSやアプリをきちんと64ビット対応にできるのであれば、プロセッサを64ビット化して動作クロック周波数を引き下げ、処理能力と消費電力を上手くバランスさせながらトータルの性能向上を図る、といったことも可能となるのです。

AppleのiPhone 5sやiPhone 6・6 Plusなどは恐らくこの方法論で(OSやアプリを含めて)64ビット対応を積極的に行っていると考えられ、また“Nexus 9”でもメインメモリが2GB搭載に抑えられていることやプロセッサの動作クロック周波数がやや低めとなっていることから、恐らく同様の考え方で64ビットプロセッサが採用されたと考えられます。

初物故のリスクはあるが将来性は抜群

以上、Nexus 9、というよりはその中のCPUとGPUにフォーカスしてみてきましたが、基本的な性能については、Android搭載タブレットとして現状で考え得る最速最強レベルにあるとみてよろしいでしょう。

また、今後主流となると考えられる64ビット命令セットをサポートしているため、長期的な利用に耐えることも期待できます。

ただ、その割に内蔵ストレージ容量が16GBないしは32GBと少なめで、しかもSDカードによる拡張も出来ないことは少々気にかかります。

またOSが久々のメジャーバージョンアップで、しかもJava仮想マシンがDalvikからARTに変更されたため、アプリ側での動作検証や対応が進むまでは、しばらくアプリの互換性問題に泣かされることになりそうです。

購入を検討される方には、こうした点を考慮して判断なさる事をおすすめしたいと思います。

▼参考リンク
Nexus 9 – Google
Tegra K1 次世代モバイルプロセッサ | NVIDIA

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

PageTopへ