なぜAndroid携帯電話はコンピューターよりもコアが多いのですか？

ラップトップには通常最大で4つのコアがあり、おそらくデュアルコアがより一般的です。最近、クアッドコアからデュアルコアに切り替えましたが、CPUを集中的に使用するタスクであっても、クアッドコアの使用例が限られていることを確認できます。

一方、携帯電話では、クアッドコア、ヘキサコア、オクタコアが一般的です。どうして？どのタスクがそれらを利用できますか？

big.LITTLEが答えの一部になる可能性があることを理解しています。つまり、非常に多くのコアの主な利点は、すべてを同時に使用できることではなく、現在のワークロードに適した消費電力のコアを使用することです。ただし、たとえば、Snapdragon 625には8つのCortex-A53コアがあり、big.LITTLEの場合はそうではありません。

たぶん、ARMアーキテクチャには、ワットあたりの最適なパフォーマンスという点が低いかもしれません。つまり、ワットあたりの最適なパフォーマンスに合わせてシングルコアを調整すると、IntelよりもARMのパフォーマンスが低下します。そのため、パフォーマンスを提供するためにより多くのコアが使用されます。これは単なる仮説です。

しかし、この場合でも、携帯電話の8つのコアなど、どのワークロードが効率的に使用できるかはわかりません。ラップトップでは、プロジェクトの完全な（非増分）コンパイルのようなものがいくつか想像できます。しかし、電話で？

• ゲームはパフォーマンスを重視する場合がありますが、通常はCPUではなくGPUのパフォーマンスが必要です。
• 理論的には、複数のコアにより、インストール時またはアップグレード時のAndroid Lollipop / Marshmallow AOTコンパイルを高速化できます（つまり、「アプリ3/121の最適化」フェーズ）。ただし、これで複数のコアを利用できるかどうかはわかりません。コードを覚えている限り、一度にコンパイルされるアプリは1つだけですが、コンパイルプロセス自体に並列性がある可能性があります。
• また、Android 7以降では、コンパイル時に複数のコアを利用できます。しかし、アイドル状態で充電中にコンパイルされると報告されているため、その利点はかなり小さいようです。少なくとも1晩電話を充電する場合は、そのようなシナリオで30分または2時間かかるかどうかは本当に気にしません。

既に述べたように、big.LITTLEの組み合わせ戦略（技術的にはHMP、ヘテロジニアスマルチプロセッシングクラスター）が、非常に多くの（時には圧倒的に多くの）コアの主な理由です。モバイルデバイスは、多くの場合、重負荷と軽負荷の両方を含む複数のシナリオに遭遇します。

消費者向けの極端な例としては、MediaTekのHelio X20があります。HelioX20は、パフォーマンス指向の2つのA72コア、4つのバランスの取れたA53コア、4つのエネルギー効率の高いA35コアを備えています。これは、さまざまな使用事例を通じて非常に柔軟です。ただし、通常は8コア 2クラスターで十分だと思います。

また、デスクトップのような別の例として、QualcommのSnapdragon 800シリーズ（S 800、S 801、およびS 805）もあります。各SoCには同じマイクロアーキテクチャのコアが4つだけあり、2つはクロックが高く、2つはクロックが低くなっています。クアルコムがこれらのSoCを作成したのは、独自のマイクロアーキテクチャ（Krait 400およびKrait 450）に非常に自信を持っているためです。

ゲームの場合、CPUではなくGPUのパフォーマンスを要求しているように見えても、CPUに大きな負荷がかかります。GPUは、処理するデータを他に提供するものがないと単独で動作することはできません。これは、ゲーム中にCPUが実行する主要なジョブの1つです。ほとんどのゲームの場合、GPUはグラフィックスのみをレンダリングしますが、データ、リソース、アセットの読み込み、システム、環境、物理学などのゲーム内メカニクスの計算など、他のすべてのジョブはCPUによって実行されます。ローエンドCPUにこだわりながらGPUをアップグレードしても、フレームレートが高くなることはありません。

二次的な理由は、AndroidがCPUリソースを使用する方法です。Androidは、ほぼ独自のアプリケーション環境を作成します。Javaのコード（およびAPI）のみを使用しますが、Dalvikという名前の独自の仮想マシンがあり、後にART（APIレベル21）に置き換えられました。APKの実行可能コードは、.classJavaのファイルによく似た「ニュートラル」形式です。実行される前に、コードはマシンのネイティブ命令にもう一度コンパイルされます^[1]。コンパイルプロセスはマルチスレッドであり、マルチコアを利用してパフォーマンスを向上させることができます。
また、アプリの実行中には、アプリと並行して、またはアプリと並行して実行される他のプロセスやメカニズム（ガベージコレクターなど）がいくつかあります。より多くのコアを使用すると、メインアプリケーションと同様に、サポートプロセスをより効率的に実行できます。
_{1.ファイルタイプ識別子を使用する場合、「最適化された」dexファイルはELF形式であり、「ニュートラル」dexファイルは独自の形式であることがわかります。}

もう1つのささいな理由は、ARMコアがIntel x86チップほど速く動作できないことです。Intel x86マイクロアーキテクチャは、Intel 8086チップの設計が開始された1976年に遡ることができます。これは、x86が長い間開発されたことを意味します。単一の最新のハイエンドARM Cortex-A73コアは、Intel Clarkdaleコアと同じくらい強力で、Core i5-660を例にしています（GeekBench、シングルコア）。これは、x86がCISCマイクロアーキテクチャであり、ARMがRISCであるためです。マイクロアーキテクチャ。あなたは確かに2つほどのアクティブなアプリで遅れる電話が欲しくありません。より多くのコアが圧力を緩和するのに役立ちます。そのため、デュアルコアSoCは、スマートウォッチでのみ比較的人気があります。スマートウォッチでパフォーマンスが必要なのは誰ですか？

興味深いことに、同じ負荷でコアを増やすと、単一のコアよりも消費電力が少なくなります。CPU周波数と消費電力の関係は直線的であるため、2倍の周波数では常に2倍以上、または3倍または4倍の電力が必要になりますが、パフォーマンスは2倍未満になります（キャッシュなどの他のリソース制限のため） ）。そのため、4つのコアが同じ負荷で単一のコアを簡単に打ち負かすことができ、パフォーマンスが向上し、同時に消費電力が少なくて済みます。

参考文献：

• スマートフォンの8コアと10コアのCPUコアが良いアイデアである理由–キッチンからの教訓
• 一部の電話に2つのクアッドコアプロセッサがあり、一部の電話に同様のクロック付きオクタコアがあるのはなぜですか。パフォーマンスの点でどちらが良いですか？

理由は複雑であるのと同じくらい簡単です。

簡単な答えは、「携帯電話市場はかつてなかったし、Intelによって動かされていないからです」。

長い答えはここで再開するには長すぎますが、基本的な概念は、Intelが長年にわたってPC市場を支配し、支払いと腐敗（そしてこのために罰金を科せられる）が彼のCPUであるということです。 PCメーカーにとって最初で唯一の選択肢。

市場を完全に制御することで、IntelはCPU価格を膨らませながら、ユーザーが必要とする機能と処理能力を人為的に決定しました。Intelの歴史を少し分析すると、その主な強みは基本的にCPU周波数の増加。したがって、ほとんどの場合、実際にスマートで革新的なことをしようとしませんでした。「コアを追加する必要はありませんが、100 MHz高速で実行できるこのジューシーな新しいCPUがあります」と言うことができるため、それは必要ありませんでした。同時に、サーバー市場でマルチコアCPUをとてつもなく高い価格で販売することができました _{（サーバーは常に必要だったため使用するサーバーを実現しようとする現在の傾向があるという点まで、... 100台の安価な電話CPUが並行して動作している）}

これは、並列プログラミングの重要性に追いついたことのない開発者コミュニティにも反映されているため、ほとんどの場合、多くの人が一度に複数のスレッドを使用することはありません-または、技術的な方法で、ソフトウェアに一度に複数のタスクを実行させる。ちなみに、顧客ベースの99％が最大で2つのコアを持っている場合、これは理にかなっています。悲しいことに、これは並列アルゴリズムの実装が本当に難しく、問題の小さなサブセットにのみ適用されるという伝説につながっていました。

代わりに、最終的に、モバイル市場はIntelの成功を見たことはありません。実際、Intelは通常のX86アーキテクチャとは異なる何かをしようとすることがほとんどであるため、実際はまったく逆です。そのため、市場の影響力とコントロールが不足しているため、他のCPU生産者は、PC市場以外の年齢層の標準である並列コンピューティングの方向に進んでいます。

進行中の2つの要因があります。1つは非常に実用的で、もう1つは歴史的です。

実際的な理由は、携帯電話での混合アーキテクチャの使用です。電力消費は電話にとって重要であり、電話はパフォーマンスがほとんど必要ないモードで多くの時間を費やします。一部のコアは、パフォーマンスがほとんど必要ないときに最小の電力消費に最適化され、一部のコアは必要に応じて最大のパフォーマンスを提供するように最適化されるのが理にかなっています。

もう1つの理由は、主に歴史的なものです。2005年頃まで、デスクトップCPUはすべてシングルコアでした。デスクトップCPUのパフォーマンスを向上させることは、1秒あたり可能な限り多くの命令を実行できるコアを作成することだけでした。今日でも、多くのデスクトップソフトウェアはマルチコアを十分に活用できないため、多くの人はコアが20％遅い8コアCPUよりも4コアのCPUを好むでしょう。

単一のコアから可能な限り多くのパフォーマンスを引き出すには、大量のCPU領域が必要です。これは、そうでなければより多くのコアを提供するために使用できる不動産です。Intelの最新のKaby Lake CPUが4コアで最大になり、各コアが前世代のコアよりも高速であるため、人々が購入するのはこのためです。多くの場合、コア数の多いCPUからのアップグレードでもあります。

時間が経つにつれて、より多くのコアをサポートするように完全に最適化されたはるかに多くのデスクトップソフトウェアが登場することを期待してください。それが起こると、エンジニアリング上のトレードオフは、デスクトップ上のより高速なコアよりも多くのコアを優先し始めます。コアはほぼ確実に高速になりますが、各コアが20％遅い場合でも、4コアCPUよりも8コアCPUを好む人が出てくるでしょう。チップ設計者は市場をフォローします。

電話が短いバーストで計算能力を提供できることは重要です（特定のアプリを高速にする必要があります）が、過熱を避けることもできます（ラップトップやPCよりも電話の方が熱放散がはるかに困難です）。これを実現するために、アーキテクトは、ワークロードが軽いときに単一のコアを使用するように電話を設計し、必要なときにパフォーマンスを向上させるために追加のコアを提供します。電話機が使用する大きなコアの数が少ない場合、ワークロードがかなり軽い場合でも、過熱が問題になります。

出典：大学院レベルのコンピューターアーキテクチャコース。

第1に、Java仮想マシンは従来、典型的なデスクトップソフトウェアよりもマルチコアの恩恵を受けることができます。Javaでシングルスレッドアプリを作成した場合でも、ガベージコレクターコードのほとんどはアプリと一緒に実行されるため、マルチコアでより高速に実行されます。

第二に、自動更新、広告ダウンロード、ウイルス対策ソフトウェア、GSMモジュールの管理など、携帯電話のバックグラウンドで多くのことが行われています。ラップトップでは、これらのすべてのタスクが1つのコアをビジーに保ちますあまり強力ではないので、レスポンシブシステムが必要な場合は、バックグラウンドタスク専用の機能を少なくとも2つ用意することをお勧めします。

最後に、マーケティングがあります。8コアの恩恵を受けるかどうかを評価できるユーザーは多くありませんが、8コアのスマートフォンは2コアまたは4コアのスマートフォンよりも確かに高価に聞こえます。

これまでの回答は、この圧倒的に多くのAndroidスマートフォンのCPUコアにつながる問題のいくつかの側面を説明しています。もう一度読んでください。Androidフォン。iPhoneは何年もの間、わずか数コアにとどまっていますが、それでもAndroidのどのフラッグシップよりもずっとスムーズに動作します。

Androidの設計者は、Javaプログラミングを選択し、その結果としてアプリケーションのランタイムとしてJVMを選択することを決定したとき、大きな賭けをしました。Javaは、その設計原理により、パフォーマンスを犠牲にすることにより、各CPUアーキテクチャで実行する前に各CPUアーキテクチャのコードをコンパイルおよびビルドする必要があるという問題を解決します。Javaは、通常JVMと呼ばれる重くてかさばる仮想マシンを導入します。JVMは実際にソフトウェアレベルでCPUをエミュレートし、デバイスごとに個別にコードをコンパイルする必要を回避します。JVMは、実行するデバイスに関係なく同じプロパティを持つ仮想CPUと考えてください。そのため、JVMに対してコードを1回コンパイルするだけで、すべてのデバイスで実行できます。これにより、メーカーはアプリケーションの互換性を心配する前に、必要なハードウェアを投げることができます。

JVM自体は単なる仕様であり、この仕様に準拠している限り、人々は独自のJVMを自由に開発できます。元のAndroid JVMはDalvikと呼ばれていました。最近、GoogleはそれをARTに置き換えました。

JVMの問題は何ですか？大量のコンピューティングリソースを消費する重いソフトウェアです。これにガベージコレクションなどのJava言語の他のプロパティを追加すると、JVMのリソース消費は、控えめなハードウェアパワーを備えたデバイスでは単純に過剰になります。デバイス上で開かれている各アプリケーションとシステムサービスは、それ自体がART JVMのインスタンスであり、これらをすべて管理するには、本当に高性能なハードウェアが必要であると結論付けることができます。ユーザーインターフェイスを描画する必要がある場合、事態はさらに悪化します。

各アプリケーションは多数のスレッドで実行されます。各CPUコアは、一度に1つのスレッドのみを実行できます。各アプリには、ユーザーインターフェイスに関連する処理を行う1つのメインスレッドがあります。ファイルアクセス、ネットワークなどを行うためのアプリケーションごとに多くのスレッドが存在する可能性があります。一般に、CPUコアよりも多くのアプリ（およびシステムサービス）が開いているため、通常はCPUコアよりもはるかに多くのスレッドがあります。したがって、各コアは異なるスレッドの処理を絶えず切り替え、各スレッドを少しずつ実行してから次のスレッドに進む必要があります。この切り替えはCPUに多くの時間を要し、アプリケーションが本質的にJVMである場合、このタスクはさらに徹底的になります。

この説明に基づいて、Androidをスムーズに実行するには強力なハードウェアが必要であると推測できます。初期のAndroidデバイスは、遅れ、クラッシュ、その他多くの不幸なことで有名でした。しかし、長年にわたり、これらの問題は強力なハードウェアに依存することでほとんど解決されてきました。

一方、iOSアプリケーションはネイティブマシンコードにコンパイルされるため、仮想化は必要ありません。使用される言語とオペレーティングシステムもより効率的であるため、過剰なチップセットを必要とせずにこれらのデバイスをスムーズに保つことができます。

上記すべてを再開すると、PCと携帯電話の使用例はまったく異なると言えます。ほとんどの場合、単一またはいくつかのアプリで使用されるPC（もちろん、多くのタブを備えたブラウザーは多くのCPUコアを必要とし、トップi-3でも遅れることがあります）、マルチタスクに使用される電話。少なくともネットワーク接続、UI描画、システムトリガー、通知。PCでタスクマネージャーを開くと、多くのプロセスもありますが、古いCore 2デュオでもCPU使用率は数％未満です。4コアはかなり安価です（MTK 65x2はOEMの開始時に1ドルのコストでした）。また、コアあたりのパフォーマンスが最後に不足した場合は、リスク対CISCです。エネルギー効率の高い！=強力な、我々がここで見ることができるように。マルチコアは、深刻な重いシングルトレッドの負荷がなく、マルチタスク向けのエクスペリエンスであるため、モバイルに最適です（ただし、優れたソフトウェアにより、iPhoneで必要なコアとRAMは少ないことがわかりますこのビデオなどで）

4または8を超える主な要因の1つ（大きい：小さい構成の場合）は、現時点では単なるマーケティングだと思います。

コア数が多いことの大きな問題の1つは、メモリのサイズを考慮することです。通常、デスクトップアプリでは、複数のコアの使用率を向上させる場合、単一のスレッドアプリケーションよりも構造を複製し、はるかに多くのメモリを使用する必要があります。

これは、RAMが非常に高価であるため（特に2017/2018 RAM危機の状況では）発生しません。マーケティングは高い数値を望んでいますが、制御はコンポーネントの価格を下げたいと考えています。コアあたり1ギガバイト未満のRAMのバランスが見られる場合は、妥協の失敗を確認しています。