コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第47回　モバイルデバイスのハードウェアを知る（パート3）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第47回　モバイルデバイスのハードウェアを知る（パート3） (中井悦司) 2018年10月

はじめに

　前回に引き続き、2018年に公開されたエッセイ「2 Billion Devices and Counting: An Industry Perspective on the State of Mobile Computer Architecture」をもとにして、モバイルデバイスの性能評価に関する話題をお届けします。前回は、モバイルデバイスのハードウェア性能評価について、「ワークロード」の観点での注意点を説明しました。今回は、「評価項目（メトリック）」と「方法論」の2つの観点になります。

性能評価項目に関する注意点

　モバイルデバイスとデータセンター向けのサーバーハードウェアでは、性能評価の項目にどのような違いがあるのでしょうか？　冒頭のエッセイでは、モバイルデバイスに固有の注意点として、次の3つをあげています。

「フレーム落ち」を起こさない
マイクロアーキテクチャーの効率性にとらわれない
「ロングテール」の体験を無視しない

　これらは、モバイルデバイスを利用するエンドユーザーの満足度に着目した注意点と言えます。たとえば、1つ目の「フレーム落ち」は、端末画面の更新速度についての注意点です。一般に、モバイルデバイスでは、快適な操作感を損なわないために、60FPS、すなわち、1秒あたり60回の画面更新速度を保つ必要があります。これは言い換えると、1回の画面更新を16.67ミリ秒で行う必要があるということです。たとえば、99%の画面更新が14ミリ秒で高速に行われたとしても、残りの1%に17ミリ秒かかったとすれば、エンドユーザーは、2秒に一度、「画面が一瞬固まる」という状況を経験します。これは、とても満足できる操作感とは言えないでしょう。
　パート1でも触れたように、現代のモバイルデバイスは複雑な内部構造を持っており、あらゆる状況において、このような画面更新の速度を保証するのは容易なことではありません。どのような性能評価を行うにせよ、まずは、このような「フレーム落ち」が発生しないことを確認するのが大切になります。
　次の「マイクロアーキテクチャーの効率性」も同様の観点です。図1は、4種類のプロセッサーについて、何パーセントの画面更新が16ミリ秒以下で行われるかを示したベンチマークの例です。

fig01

図1 画面更新速度のベンチマークの例（エッセイより抜粋）

　丸と三角の記号で示された2種類のプロセッサーは、それぞれ、2.15Gヘルツ、および、1.67Gヘルツの動作周波数を持っており、この数値だけを見ると大きな性能差があるように思われます。しかしながら、このベンチマークでは、どちらも100パーセントの画面更新が16ミリ秒以下に保たれており、実質的には1.67Gヘルツの性能で十分、あるいは、消費電力などを考えると、1.67Gヘルツのプロセッサーの方が好ましいと言えます。一方、四角の記号のプロセッサーは、1.13Gヘルツで動作しますが、10パーセント前後の画面更新に16ミリ秒以上の時間がかかっており、エンドユーザーの視点では、大きな問題を抱えた状況です。個々のパーツの性能だけに着目していると、このようなエンドユーザー視点での価値を見落とすことがあるというわけです。
　これは、画面更新速度だけに限るものではありません。図2は、数億ユーザーが利用するGoogleのモバイルアプリケーション（2種類）について、特定イベントに対する応答時間の分布を示したものです。

fig02

図2 2種類のアプリケーションにおける応答時間の分布（エッセイより抜粋）

　平均的にはどちらも500ミリ秒程度の応答時間ですが、非常に長い裾野（ロングテール）が伸びており、中には4000ミリ秒を超えるものもあります。複数の処理が連携して動作するアプリケーションには、いずれか一つの処理が遅延するだけでも、全体の応答時間が伸びるという特性があります。ハードウェアの設計変更で平均的な応答時間が短くなったとしても、裾野の方は、逆にさらに大きく伸びるといったこともありえます。このようなロングテールの存在に注意を払わないと、エンドユーザーの満足度を損なう可能性があるというわけです。

ベンチマークの方法論に関する注意点

　モバイルデバイスのベンチマークにおける、その他の一般的な考慮点としては、次の3つが挙げられています。

アプリケーションのハードウェア依存性を考慮する
IP（ネットワーク）処理機能を考慮する
エネルギー消費と発熱量を考慮する

　これもパート1で触れた点ですが、現代のモバイルデバイスでは、SoC（System on Chip）と呼ばれる、CPUとその他の周辺機能を1つのチップ上にまとめて実装する方式が採用されており、デバイスごとにハードウェア機能にさまざまな違いがあります。そのため、モバイルアプリケーションでは、ハードウェア機能に応じて処理内容を変更するという最適化が行われます。たとえば、動画の描画処理であれば、ハードウェアアクセラレーターの有無によって、実行されるコードが変わります。したがって、複数のハードウェアの性能を比較する際は、アプリケーション側の最適化の違いを考慮する必要があります。最適化対象外のハードウェアで高い性能が出なかったとしても、それは、必ずしもハードウェアだけの問題とは言えません。
　そして、SoCのアーキテクチャーにおいて、チップ上で物理的に大きな面積を占めるのが、IP（ネットワーク）処理のブロックです。4Kビデオのように大量のネットワーク処理を必要とするアプリケーションが増える中、ネットワーク処理の性能向上は重要な課題ですが、一方で、物理的なチップサイズは限られています。ネットワーク処理に関わるブロックの最適化は、今後のチップ設計における重要な研究テーマになると考えられます。
　そして最後は、エネルギー消費量と発熱量の観点です。ハードウェアの処理性能については、「18ヶ月で2倍になる」という、ムーアの法則が語られることが多いですが、モバイルバッテリーの容量には、このような法則はあてはまりません。これまでの実績としては、「10年で2倍」というのが現状です。これと同様に、物理的に動作する冷却ファンを持たない、モバイルハードウェアの冷却性能にも劇的な向上は見られません。したがって、モバイルデバイスのハードウェア設計においては、今後も、エネルギー消費量と発熱量の制限を確実に考慮する必要があります。これらを無視して高い性能を実現しても、その実用的な価値には疑問符がつくことになります。

次回予告

　今回は、2018年に公開されたエッセイ「2 Billion Devices and Counting: An Industry Perspective on the State of Mobile Computer Architecture」をもとにして、モバイルデバイスのハードウェア性能評価における考慮点、特に「評価項目（メトリック）」と「方法論」の観点での注意点を説明しました。前回とあわせると、全部で9つの注意点が示されましたが、このエッセイには、最後にもう一つ、「このリストは完全なものではない」という注意点が記載されています。音声認識機能の向上などを考えると、モバイルデバイスの利用方法は今後も大きく変化する可能性があり、ハードウェア設計の方針にも影響を与えるだろうとの指摘でこのエッセイは締めくくられています。
　次回は、久しぶりに、少しばかり本格的な機械学習の話題をお届けしたいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡