iPhone XRのGPU性能はMacBook Pro相当……専用命令でも増えたか？
この記事には全面的な誤りがあるため、参考にはしないでください。
この記事を参考にされた方には、誤ったデータを示した事をお詫び申し上げます
間違っているデータの根拠につきましては最後に掲載しております。
ITmediaの記事であるが、MACお宝鑑定団Blogのもので推定実効性能を示している。まあ、これがGPUそのものの性能というわけではない。まあ、AプロセッサはiOSでしか使われないため、実効性能＝性能となるのは仕方がないのだが、厳密にはSoCの性能が他を凌駕するほど高い訳では無いとも言える。
http://www.itmedia.co.jp/news/articles/1810/23/news131.html
http://www.macotakara.jp/blog/
＜Androidに対する強み＞
ここから分かる事は、XR（に限らないが）のGPUはFP32ベースで500 GFlopsを超えていないという事を意味している。MacBook ProのUHD Graphics 630は423.2 GFLOPSであることを考えると、それ以下か同等であると思われるのである。
元々、AppleのiOS搭載スマホやタブレットは、中間関数処理が殆ど行われていない。そのため、オーバーヘッドがほぼゼロで直接ハードウェアに命令を伝えることができることは知られている。だからこそ、実際のプロセッサ性能は少し低めでも、高い実効性能が出せるわけだ。そこで、単純なスペック比較ができない隠蔽をするという意味と、ブランド力の強化、部品納入コストの削減から自社開発のGPUやCPUに変更したと見られる。
その効率がまた一段と上がっているように見えるのは、たぶんMetal（iOSのAPI）専用の命令セットを何らかの形で加えているのだろう。底上げ率はAndroidに比べると2倍を超えていると思われる。
ちなみに、Google Androidで最速となるSnapdragon 845に搭載されるAdreno 630のFP32は720 GFlops（710MHz稼働時）である。独自ブーストなどが搭載されていれば、1MHz辺り1 GFlopsの割合でFP32性能は上がると考えられる。しかし、これほどのGPUを実装していながらAndroid上での実効性能はAppleのiOSを下回るわけだ。即ち、iOS側でのGPU命令実効性能はandroidの2倍を超えたことになる。CPUについてはここまで差が開いている訳では無い。
しかも、GPUが外部ベンダー製品だったころに比べて、自社開発になってから大幅に伸びていることを考えると、Metal APIに最適化するために、Apple A SoC側にそれ専用の追加命令が加わっている可能性が高いと考えられる。
これは、昔のPlaystation 3のようなゲーム機がやって来た手法と同じ方向にはっきりとAppleが向かっていることを意味している。そして、Androidではここまで最適化することはできない。まあ、GoogleがApple並に専用設計を加えて自社開発するものなら出来るかも知れないが……
＜Androidにはできない事をやるApple＞
そもそも、AndroidはWindowsや他のLinux Distribution、UNIXと同じで、汎用性の高い。しかもAndroidはオープン系のOSである。そのため、ハードウェアも自由に設計でき、それに合わせて多くのドライバーが開発されている。それ故にアプリケーション実行環境を統一するためにレイヤー（階層）がいくつか並列または重なって実行環境が構築されている。
端的に言えば、SnapdragonでもHelioでも、Kirinでも使えるということだ。AppleならApple Aだけに対応していればそれでよいから、それぞれに合わせたルーチンを用意する必要は無い。これでコードは大幅に節約できる。
重要なのはここからだ。SnapdragonとHelioでは、得手不得手が異なる。いやもっと正確に言えば、Snapdragonの中でも845と450では使える機能やGPU性能のバランスが異なる。これが実はOSにとってタイムロスという壁を生み出す（待ちを増やす）ことになる。体感（実行）性能を低下させるのだ。
アプリケーションソフトというのは、表示、入力、演算、出力という工程のいずれかまたは全てをプログラミング命令に基づいて行っている。その中で、GPU処理を多用するゲームなどでは、これらの全てを同時に行っていることが多く、CPU、GPU、DSP、さらに製品によってはカメラISPまで使って処理を行う。
その際に、CPUの演算結果とGPUでの処理結果を利用してDSPやカメラを動かすという場面が伴ったり、CPUで結果を出したあと、それを元にGPUで処理するというはよくあることだ。即ち、お互いのハードウェアが同期している訳だ。Appleの開発するAプロセッサの場合、自社開発のプロセッサとOSを使うことで、この同期をハードウェアレベルで最適化することができる。即ち、ほとんど待つことなく処理を行う事もできるようになる。
それに加えて、自社開発のOS同期に最適な追加命令セットでも足しておけば、処理はより効率化する。しかも、最小のエネルギー効率で最大の能力を発揮するようになる。
Appleが最近、APIを自社向けに特化させ始めOpen系APIを外したのはそこにあると思われる。そのうち、デスクトップでもIntel離れが始まるかも知れないと言われるのもここから来ている。
しかし、Androidでこれをやろうとすると、デバイスに使うパーツをある程度選別し固定しないと、難しい。
得手不得手の差によって、SoC毎のギャップがあるためだ。もちろんパーツを選別してこれしか使うなという話になると、Androidの価値は失われる。様々なハードがあるからこそ売れている側面もおおきいからだ。
もちろん、アプリケーション側でHelio専用やSnapdragon 660専用のように設計をすれば、特定のアプリでそのプロセッサだけ性能を引き上げることは出来るかも知れないが、それをやれば今度はSnapdragon 845など他のプロセッサでは期待値に比べて性能が落ちる可能性もある。
実際に、今はほぼ無くなったが、ARTを搭載する前のAndroid 4.x世代まではSnapdragon向けの最適化が行われていたアプリも多くあったが、今は低価格スマホでの他社プロセッサ搭載も増えたこととランタイム環境が変更になったことで、ほぼ無くなった。
即ちこれが、Appleにとって最大の武器になる訳だ。専用機だからこそできる話という訳だ。
＜今後も差が開く？欠点は無いのか？＞
この路線は今後も続くと思われる。これはAppleが唯一オープン系や商用の汎用OSに今後も勝り続けることができる部分だからだ。ただし、これに死角が全く無いのかというと、実はある。
それは、切り捨てである。
この高い効率を維持し続けるには、古い機能を一定感覚でそぎ落とし続けなければいけない。要は、3年なら3年、5年なら5年といったタイミングで古い物を完全にバッサリ切り落とし、アプリの開発も出来ない状態にし続けないと、最新の命令やコード最適化によるパフォーマンス向上の恩恵は得られなくなる。
まあ、iOSなどのモバイルプラットフォームでは開発が終了している個人アプリ等を除けば、基本的に更新サイクルが早く、正確で常時更新が行われているため、あまり切り捨ては起きないが、人気が低迷するような事態になると、苦しくなるかも知れない。
ただ、現状では上手く行っており、上手く行っているからこそどんどん最適化を進めていると考えられる。
＜MacBook Pro相当と言ってよいのか？＞
では、これは本当にGPUがMacbook Pro相当と言って差し支えないのか？というと、難しいところだ。そもそも、汎用プロセッサとして展開されているIntelやAMD、Qualcomm（Arm）とは異なり、これはあくまでApple専用であり、iOS専用だからだ。即ち、純粋に同じプラットフォーム環境での比較ができないのだ。汎用で見るなら最低でもOpenCLやOpenGLなどのAPI対応のドライバがなければ、同等というわけにはいかない。評価するならOS側の効率を評価すべきであって、GPUが高性能だとは限らないのである。
まあ、Appleが好きな人なら、どっちでも変わらないのかもしれないが、しっかり正しく評価するのであれば、GPUとOSを最適化していると考えて評価した方がよいだろう。
匿名様
コメントありがとうございます。誤解されても仕方がないと思いますが、壮大な誤解があるようなので改めて書かせていただきます。
中間関数処理が行われていないのではなく、Androidに比べて直接的なキック処理が多いと言う意味で、殆ど使われていないと書いております。ゼロではなく、Objetive-Cによるネイティブコードが多いと私は見て書きました。
「それってデベロッパーからは見えない部分なのでは？」
確かにアプリケーションソフトを作っている側から見えない部分が多分に含まれます。プログラマーなど開発者に見える部分だという断言もしてはいません。
根拠を説明します。
AndroidのコンパイラはJIT/AOTコンパイラなのでインストール後実行時変換します。それに対して、iOSはPCと同じコンパイラ変換済みをインストールする仕組みになっているはずです。この時点でiPhoneよりAndroidの方がオーバーヘッドは大きくなります。Androidはハードウェア仕様の違いが機種毎に大きくあるため、この仕様を採用しており、VMまでの中間処理工程が多くなり、その代わり性能オーバーヘッドが大きくなります。
JITの挙動仕様については以下を参照して下さい。他にもいくつかありますけど、割愛させていただきます。
https://source.android.com/devices/tech/dalvik/jit-compiler
一方で、iPhoneは全てのハードを自社設計しているため、コンパイラで先に固めることが出来ることを売りにしていたはずです。だから、ゲーム等でもiPhoneが高速といった話があったはずで、Swiftの仕様ではコンパイルで固めていたと記憶していますが……仕様が変わったのでしょうか？こちらは、推測が相当程度含まれているので、ソースはお示しできません。ソース根拠の要求にお応えできず申し訳ありません。
https://www.apple.com/jp/swift/
MacとiOSの場合は、周辺機器の拡張に関する制御系に差があることは見なくても分かります。
そのため、一部のシステムサービスはMacOSにはあってもiOSにないことが予想されます。同様にiOSには搭載して、MacOSではオプショナルな機能もあるでしょう。タッチインタフェースとか……。そういう部分を考えれば、Apple A GPU独自拡張を追加してSwiftのコンパイラで隠蔽を掛けていれば、GPUの性能を他社GPU以上に引き上げることも出来るでしょう。
この辺りを私は関数の差と丸めてしまっています。ここに誤解があったのであればお詫び致します。また間違いがあるようなら、情報をいただければ修正致します。なお、実行アプリケーションソフトの性能では関係ないからこんな記事は関係ないという話なら、そうかもしれません。
「あと、metalで処理が早くなるのはほんの一部で他の性能はOpenGLと変わりません。どうせプログラマーでもないあなたがよくもまあこんな知ったかぶった痛い記事かけますねwww 」
そうですね。私はPGではありません。その通りです。痛いのは自覚していますし、コードの書き方に大きな差違はないのも知っております。その点は認めますし、質問者様がPGなら質問者様の方が詳しいところも多いと思います。
ただ、知ったかぶりで痛くても、ここは私の書いている個人Blogなので書くのは自由だとも思っています。これだけは余計なお世話です。
それから、私が囓った言語はスクリプトも含めると、本を買って勉強した物も含めて、
BAISC
Visual Basic、
C言語
COBOL
ActivePerl、
HTML4～、
WSH/VBS、
PowerShell、
Windows CMD、
UNIX（Solaris）/Linux（Turbo/RHEL）向けのスクリプト。
この中でCOBOLは読んで僅かに修正できる程度のデバッグのみです。殆ど、コマンドスクリプトみたないレベルで主にPC系（Windows/MS-DOS/それ以前）なので、化石みたいなものですし、PG（プログラマー）ではありませんし、SEとCE、OPの間のような仕事をしてきたので、広く浅い知識で、１から設計したのは２～３しかありません。いずれも業務用の管理ウェアでチープなものです。PGについて記事を書いてくれと言われても、洗練されておらず癖が強いので、無理です。しかもセンスがないので、これを作ると決めてから完成するまで他の人より日数が掛かるので……好きでも人にコードの書き方を教えたりは出来ないのです。だから本格的なPG設計をしている方は尊敬します。
また、画面制御系はあまり行うことがなく、どちらかというと組織企業向けで仕事をしてきましたので、認識の誤りがいくつもあるのかもしれません。こういうのが好きなので、コアな設計書や仕様書は読んで勉強していますが、全部を理解することも出来ません。そんなレベルですが、もし、間違いがあるなら、笑うのではなく、教えていただければありがたいと思います。
私のスタンスは、基本的にハードウェアの基本性能ありきなので、コード書きから見てどうかではないことをご留意いただければと思います。
それから、最後に大事なことなので、もう一度書いておきますが、Blogで自分の記事を書くのは自由です。PGじゃなから、記事は書くなとか、専門家しか記事を書いてはいけないという世の中になるようでは、自由な主張が出来る社会は終わります。プログラマーはハードのことなんて知らないんだから、ハードのことなど書くなと言われるのと同じです。電気屋さんで働いていないと、掃除機の比較はしちゃいけない？とか？そういう話になるかもしれません。
私が、匿名様とコメントを交わせるのも、匿名様が私にコメントが出来るのも、この記事があってこその縁であると思います。そこから、私自身も学び、匿名様も私のことをご理解していただけるかも知れない。
それだけでも、この記事には意味があります。
これを機会に、当ブログに足を運んでいただければ、嬉しいのですが、
腹が立つ記事しかない馬鹿にするしかないと思われるなら、当ブログに足を運び記事を読むのは、避けていただければと思います。記事を馬鹿にされると、私もいい気はしませんので、あまり繰り返されるなら、相応の対応をせざる終えなくなります。
もし、今後も足を運んで下さるなら、出来れば馬鹿にして笑うのではなく、ご意見としてここの見解がおかしいのではないかとか、そういう建設的な形で書いていただければ幸いです。私自身間違いもありますし、後から見て、自分でも赤面するような記事もありますから。Blogを辞めない限り消さないけど……。あと、出来れば極端に古い記事は修正が大変なので……指摘されても、指摘をそのまま置いて放置するか、本文対応しないかもしれません。（記事アクセス数次第です）
匿名様
再コメントありがとうございます。悪い方でなくてよかった。
私の方こそ、拙い内容で申し訳ない限りです。
匿名様の内容を読む限り、知識ベースと互いが主張している内容が違うように見え、匿名様の考え方も正しいと思われます。
匿名様は常に書いたコードの範疇でどう動くかを見ておられるようです。実効性能をプログラミングした結果の挙動だけで考えて見るとそれで正解です。PGにも差も無いのだから、むしろ私の解釈がおかしく見えるのでしょう。
私は、コードをOSで実行する際に、どんな経路を辿りハードウェアに到達するか？そのハードの仕様がどの程度の物かを基にしてOSの仕組みとしてどうなのかを書いています。ネイティブというのを使ったのは、OS毎の抽象化レベルが違うという説明に繋がるだろうと単純に思って使ったのですが、常に動かすアプリケーション目線で捉えられているようなので、これでは説明になっていないと気が付きました。
この記事のタイトルを原点にもう一度書いておきます。
この記事はハード一つ一つの部品における物理性能を基にすると、PC側とスマホ側の数字が合わないという前提があり、それを考えて書いた記事です。その中に専用命令という部分があって、そこに目を奪われているのだと思います。ソースコード上の差がなければ、専用命令は追加されていないのではないかと。その辺りも含めて全部書きます。そこに認識の差があるようです。
まず、
>TFLOPSがGPUの素の性能と見るのはナンセンスです。
その通りですが、ではどこで差が出るのでしょうか？それを説明しなければいけません。
それを説明できなければ、アプリケーションとしての性能で、約2倍高効率というケースもあるという結論になってしまいます。
例えばGPU性能、1TFlops（1000GFlops）と500GFlopsなのに同じゲーム（OSは異なりプログラミングに使ったコードはほぼ同じ）を実行すると、ほぼ同じ描画性能なのかという場合、何で性能差を示すのか？考えてください。
これは、ハードウェアオタクじゃ無ければ理解出来ないかも知れませんが、
ROPか？それとも、Shader Modelか、ビデオメモリーや帯域幅か？ドライバーか？コアクロックか？このうち、コアクロックは浮動小数点演算の性能差になるため、除外しなければなりません。ビデオメモリーや帯域幅だけでは同じ解像度時のコアの絶対性能は上がらないため、これも多少は影響しますがベンチでは大きくはないでしょう。ROPの数はメモリー出力の並列性を高めますが、これも解像度に対してのみ有効です。この中で、唯一純粋に全体のゲーミング描画に影響を与えるのは、Shader Model等命令セットの追加です。
この記事はタイトルにあるように、命令セットが追加されてそれをコンパイラ側で自動認識して隠蔽している可能性がなければ、その差を埋められないと考えたものです。
ただ、iOSは周辺機器やアプリの差からカーネル切替時間が違うはずなので、それをさらに突き詰めて改善した可能性もありえます。実際、そうコメントされたら、それに、その可能性もあると同意を示さざる終えなかったと言えます。
尚、コード書き（PG）側から見た何かが変わる訳ではありません。（変わらないことがある理由は後述します）「GPU性能はMacBook Pro相当」という部分において、GPUの純粋性能はMacBookの方が上で、効率はiOSが上ということだけなのです。
この効率を変えているのは、アーキテクチャの差とOSの処理方法です。この辺りは、プリエンティブマルチタスクのカーネル制御時間の制御などを調べていただければと思います。OSの種別が変わると、制御時間や方法は変わります。ただ、OSが変わるとその差をこことここが違うから、時間が何ミリ秒違うと説明することは出来ません。
処理目的などに合わせて、構造が異なるため、単純比較は出来ないのです。
これを、最も分かり易い例で言えば、ゲーミングOS（Playstation OSなど）でしょう。
これは、GPUやCPUの性能はPCより低いのですが、PCに近い質感を実現できます。これは、周辺機器が限定されていたり、表（フォアグラウンド）や裏（バックグラウンド）で動くアプリケーションの数が決まっていると、VM（アプリケーションを動かす仮想実行環境）切替を監視する工程が不要になるため、CPUやGPUの処理効率が大幅に上がるという特徴から生まれる差によるものです。
他にも、HPCの京速コンピュータ「京」のノード実行効率などもそういう部分を突き詰めた結果、コンパイラの仕組みを最適化し分散処理の効率を大幅に上げているのです。
PCが、例えMetalのような機能を使っても、ゲーミングOSと同じ性能が発揮できないのは、カーネルが管理する割り込み（方法、時間、受け渡し手順等）や監視の数に差があるからです。
その割り込みが、ミリ秒以下でぱっと見た時に見かけの差が見えなくても、数が多ければ、速度に影響を与えます。特にGPUのような膨大な並列数と演算数を持つ回路とのやりとりはそれがかなり大きくなり、CPUもコア数が増えサービスが増えている昨今では馬鹿になりません。これが、iOSとmacOSの差になります。
ただ、これだけではちょっと足りないように見えたのです。
スマホのような電力効率を求めるモバイルプラットフォームの製品は、消費電力の効率も大事です。何か命令を追加しているものの、実際にコードを書くときに差は見えないという可能性がないと、熱効率や電力効率が悪化しますから、SoCプロセスノードとの兼ね合いを見ると、専用命令を増やした方が効率的です。
では、命令セットを増やしたなら、命令セット分の新しいコード記述が増えるのではないかと思われるでしょう。しかし、それも実は必ず増える訳ではありません。
これは、Intel AVXやAVX2、Hardware T&LのSSE置き換え、HLSLの世代交代などで、同じコードのまま新コンパイラを使えば、一部を新命令に振り替え、加速するというコンパイラやハードウェア機能もあります。置き換えや振り替えは珍しいことではないのです。そういうレベルの変更なら、コードを書いているユーザー（プログラマー）にこのように書きなさいと示す必要もありません。そして、ハードやドライバ（OS）の世代が対応したものに変わり、コンパイラの世代が変わるとそれが機能するようになります。
尚、Andorid Run Timeの構造差とiOSのネイティブ実行の差という言い回しは、iOSはハードウェアを固定しているため、Android Run Timeの仮想マシンほど仮想化時オーバーヘッドがないという前提を説明するために書いたものです。Androidはx86とArm（ArmでもSnapdragon 、Helio、Kirin）といった、各種プラットフォームとさらに、様々な周辺機器とのやりとりを想定しており、その際にコンパイル済みのコードをインストールすると、実行環境が複雑化してしまう（重たくなったり、セキュリティ上の脆弱性になる）という欠点があったのです。
そこで、JIT/AOTではハードウェアの仕様に合わせて、インストールまたは実行時にその環境に最適かされた形でコンパイルを行う仕組みを取りました。そして、実行環境は、Android VMで割り込み範囲等もインストールで指定した範囲に留めるように最初に決めおくことで、オーバーヘッド性能の低下（不要な割り込みを最初から除外する）を抑え、アプリケーションによるセキュリティ寝食も起きないように分離したのです。
そうすることで、ハードの差もVMが吸収してくれるため、互換性の問題も減らせ、性能もハードウェアに合わせて最大になるように最適化されます。
それでも、iOSよりハードの種類が多く、全体に対応させるとどうしてもコードが増え、さらに仮想マシンのボトルネックは必ず出てきます。Androidの根幹となるシステムは迂回コードがカーネルやサービスに多くありますので。そこが、高度連続実行時の性能におけるボトルネックになる訳です。だから、iOS並の実効性能を得るには、パワフルなプロセッサが必要になります。
このAndroid で使うVMの仕組みに繋がるART（Android Run time）はiOSにはありません。ARTはRuntimeですから、いわゆる関数群であり、その仕組みはiOSにはありません。このARTは開発者から見て特別な何かではありません。そもそも、ARTは実行環境そのものですから。ただ、ARTの仕組みはiOSより複雑でオーバーヘッドが大きいのです。それを、JIT/AOTという構造で可能な限り減らしている訳です。
iOSやMacOSの場合は、Darwin（NeXTSTEP）がカーネル管理をしていますが、ハードウェア開発が一本なので、ARTのような構造は不要なのです。どちらかというと、ゲームOSのように設計できます。何故なら、ハードウェアはApple製品しか無く、周辺機器もアプリも基本Appleが認めたもののみになります。その分、障壁が軽く、ARTと比べると実行系統は殆どネイティブで実行されます。セキュリティはAppStore側の認証を厳しくすることで担保しているのも、これの特徴です。
この部分で、説明が足りなかったのがたぶん不味かったのだと思います。
これで、全ての説明になっているかな？
なっていなかったらごめんなさい。力不足です。
＜匿名様＞
こちらこそ、大してアクセス数もない記事にわざわざお付き合いしていただいて申し訳ない限りです。
改めてこちらのデータを再調査した結果でお知らせします。
実は、前の追加を書いた後に私側も本当に大丈夫なのかと電卓を弾いたり、ベース資料や発表資料などを調べていました。当該記事を書いた時にも、可能性はあるけど、まさかと思いながら書いていたのが情けない。ハッ、こういう大丈夫だろうとか、間違っていないだろうというのが、特殊詐欺被害に遭う人のタイプなのかも？などとも思いながら。
全体を調べ直した結果、当方に根本的なミスがありました。Intel GPUの計算値を誤っていたようで、上記のiPhone7のものと同じで、820～870GFlops(FP16）の半精度で計算していたという……こんな記事まで書いているのに恥です。一方で、A11比、～1.5倍で換算すると、FP32で最大624～672.75GFlops（もう少し誤差があるのですけど）でした。
これは、こちらの全面的な凡ミスであると言わざる終えません。
計算から逆算すると、Intel GPUやCPUの方が効率は良いということになりました。
尚この記事は削除すると、既に閲覧した人が再閲覧で参考にされるときに、誤っていることを識別出来ない恐れがあるため、恥ずかしい内容ですけど、掲載は継続致します。もし、匿名様のコメント削除をご希望の場合は、コメントにてお知らせいただければ、コメントについては削除致します。
長い時間を掛けて、当方のミスにお付き合いいただき、そしてご指摘いただき本当にありがとうございました。
閲覧された方々にも間違いを掲載したことにつきまして、お詫び申し上げます。
それから、差し支えなければで良いのですが、今後のために一つ確認させてください。
>iPhone7の時点で約500GFLOPSほどあるので
という数値はどういう情報を基にした計算なのかを教えていただけないでしょうか？私の調べた範囲では、iPhone 7のGT7600PlusのFP32は310～345GFlops（FP32換算）になり、500GFlopsを超えるとしたらFP16（半精度演算）で、その倍数未満になるのではないかなと思うので、出来れば確認いただけると幸いです。
この記事を参考にされた方には、誤ったデータを示した事をお詫び申し上げます
間違っているデータの根拠につきましては最後に掲載しております。
ITmediaの記事であるが、MACお宝鑑定団Blogのもので推定実効性能を示している。まあ、これがGPUそのものの性能というわけではない。まあ、AプロセッサはiOSでしか使われないため、実効性能＝性能となるのは仕方がないのだが、厳密にはSoCの性能が他を凌駕するほど高い訳では無いとも言える。
http://www.itmedia.co.jp/news/articles/1810/23/news131.html
http://www.macotakara.jp/blog/
＜Androidに対する強み＞
ここから分かる事は、XR（に限らないが）のGPUはFP32ベースで500 GFlopsを超えていないという事を意味している。MacBook ProのUHD Graphics 630は423.2 GFLOPSであることを考えると、それ以下か同等であると思われるのである。
元々、AppleのiOS搭載スマホやタブレットは、中間関数処理が殆ど行われていない。そのため、オーバーヘッドがほぼゼロで直接ハードウェアに命令を伝えることができることは知られている。だからこそ、実際のプロセッサ性能は少し低めでも、高い実効性能が出せるわけだ。そこで、単純なスペック比較ができない隠蔽をするという意味と、ブランド力の強化、部品納入コストの削減から自社開発のGPUやCPUに変更したと見られる。
その効率がまた一段と上がっているように見えるのは、たぶんMetal（iOSのAPI）専用の命令セットを何らかの形で加えているのだろう。底上げ率はAndroidに比べると2倍を超えていると思われる。
ちなみに、Google Androidで最速となるSnapdragon 845に搭載されるAdreno 630のFP32は720 GFlops（710MHz稼働時）である。独自ブーストなどが搭載されていれば、1MHz辺り1 GFlopsの割合でFP32性能は上がると考えられる。しかし、これほどのGPUを実装していながらAndroid上での実効性能はAppleのiOSを下回るわけだ。即ち、iOS側でのGPU命令実効性能はandroidの2倍を超えたことになる。CPUについてはここまで差が開いている訳では無い。
しかも、GPUが外部ベンダー製品だったころに比べて、自社開発になってから大幅に伸びていることを考えると、Metal APIに最適化するために、Apple A SoC側にそれ専用の追加命令が加わっている可能性が高いと考えられる。
これは、昔のPlaystation 3のようなゲーム機がやって来た手法と同じ方向にはっきりとAppleが向かっていることを意味している。そして、Androidではここまで最適化することはできない。まあ、GoogleがApple並に専用設計を加えて自社開発するものなら出来るかも知れないが……
＜Androidにはできない事をやるApple＞
そもそも、AndroidはWindowsや他のLinux Distribution、UNIXと同じで、汎用性の高い。しかもAndroidはオープン系のOSである。そのため、ハードウェアも自由に設計でき、それに合わせて多くのドライバーが開発されている。それ故にアプリケーション実行環境を統一するためにレイヤー（階層）がいくつか並列または重なって実行環境が構築されている。
端的に言えば、SnapdragonでもHelioでも、Kirinでも使えるということだ。AppleならApple Aだけに対応していればそれでよいから、それぞれに合わせたルーチンを用意する必要は無い。これでコードは大幅に節約できる。
重要なのはここからだ。SnapdragonとHelioでは、得手不得手が異なる。いやもっと正確に言えば、Snapdragonの中でも845と450では使える機能やGPU性能のバランスが異なる。これが実はOSにとってタイムロスという壁を生み出す（待ちを増やす）ことになる。体感（実行）性能を低下させるのだ。
アプリケーションソフトというのは、表示、入力、演算、出力という工程のいずれかまたは全てをプログラミング命令に基づいて行っている。その中で、GPU処理を多用するゲームなどでは、これらの全てを同時に行っていることが多く、CPU、GPU、DSP、さらに製品によってはカメラISPまで使って処理を行う。
その際に、CPUの演算結果とGPUでの処理結果を利用してDSPやカメラを動かすという場面が伴ったり、CPUで結果を出したあと、それを元にGPUで処理するというはよくあることだ。即ち、お互いのハードウェアが同期している訳だ。Appleの開発するAプロセッサの場合、自社開発のプロセッサとOSを使うことで、この同期をハードウェアレベルで最適化することができる。即ち、ほとんど待つことなく処理を行う事もできるようになる。
それに加えて、自社開発のOS同期に最適な追加命令セットでも足しておけば、処理はより効率化する。しかも、最小のエネルギー効率で最大の能力を発揮するようになる。
Appleが最近、APIを自社向けに特化させ始めOpen系APIを外したのはそこにあると思われる。そのうち、デスクトップでもIntel離れが始まるかも知れないと言われるのもここから来ている。
しかし、Androidでこれをやろうとすると、デバイスに使うパーツをある程度選別し固定しないと、難しい。
得手不得手の差によって、SoC毎のギャップがあるためだ。もちろんパーツを選別してこれしか使うなという話になると、Androidの価値は失われる。様々なハードがあるからこそ売れている側面もおおきいからだ。
もちろん、アプリケーション側でHelio専用やSnapdragon 660専用のように設計をすれば、特定のアプリでそのプロセッサだけ性能を引き上げることは出来るかも知れないが、それをやれば今度はSnapdragon 845など他のプロセッサでは期待値に比べて性能が落ちる可能性もある。
実際に、今はほぼ無くなったが、ARTを搭載する前のAndroid 4.x世代まではSnapdragon向けの最適化が行われていたアプリも多くあったが、今は低価格スマホでの他社プロセッサ搭載も増えたこととランタイム環境が変更になったことで、ほぼ無くなった。
即ちこれが、Appleにとって最大の武器になる訳だ。専用機だからこそできる話という訳だ。
＜今後も差が開く？欠点は無いのか？＞
この路線は今後も続くと思われる。これはAppleが唯一オープン系や商用の汎用OSに今後も勝り続けることができる部分だからだ。ただし、これに死角が全く無いのかというと、実はある。
それは、切り捨てである。
この高い効率を維持し続けるには、古い機能を一定感覚でそぎ落とし続けなければいけない。要は、3年なら3年、5年なら5年といったタイミングで古い物を完全にバッサリ切り落とし、アプリの開発も出来ない状態にし続けないと、最新の命令やコード最適化によるパフォーマンス向上の恩恵は得られなくなる。
まあ、iOSなどのモバイルプラットフォームでは開発が終了している個人アプリ等を除けば、基本的に更新サイクルが早く、正確で常時更新が行われているため、あまり切り捨ては起きないが、人気が低迷するような事態になると、苦しくなるかも知れない。
ただ、現状では上手く行っており、上手く行っているからこそどんどん最適化を進めていると考えられる。
＜MacBook Pro相当と言ってよいのか？＞
では、これは本当にGPUがMacbook Pro相当と言って差し支えないのか？というと、難しいところだ。そもそも、汎用プロセッサとして展開されているIntelやAMD、Qualcomm（Arm）とは異なり、これはあくまでApple専用であり、iOS専用だからだ。即ち、純粋に同じプラットフォーム環境での比較ができないのだ。汎用で見るなら最低でもOpenCLやOpenGLなどのAPI対応のドライバがなければ、同等というわけにはいかない。評価するならOS側の効率を評価すべきであって、GPUが高性能だとは限らないのである。
まあ、Appleが好きな人なら、どっちでも変わらないのかもしれないが、しっかり正しく評価するのであれば、GPUとOSを最適化していると考えて評価した方がよいだろう。
匿名様
コメントありがとうございます。誤解されても仕方がないと思いますが、壮大な誤解があるようなので改めて書かせていただきます。
中間関数処理が行われていないのではなく、Androidに比べて直接的なキック処理が多いと言う意味で、殆ど使われていないと書いております。ゼロではなく、Objetive-Cによるネイティブコードが多いと私は見て書きました。
「それってデベロッパーからは見えない部分なのでは？」
確かにアプリケーションソフトを作っている側から見えない部分が多分に含まれます。プログラマーなど開発者に見える部分だという断言もしてはいません。
根拠を説明します。
AndroidのコンパイラはJIT/AOTコンパイラなのでインストール後実行時変換します。それに対して、iOSはPCと同じコンパイラ変換済みをインストールする仕組みになっているはずです。この時点でiPhoneよりAndroidの方がオーバーヘッドは大きくなります。Androidはハードウェア仕様の違いが機種毎に大きくあるため、この仕様を採用しており、VMまでの中間処理工程が多くなり、その代わり性能オーバーヘッドが大きくなります。
JITの挙動仕様については以下を参照して下さい。他にもいくつかありますけど、割愛させていただきます。
https://source.android.com/devices/tech/dalvik/jit-compiler
一方で、iPhoneは全てのハードを自社設計しているため、コンパイラで先に固めることが出来ることを売りにしていたはずです。だから、ゲーム等でもiPhoneが高速といった話があったはずで、Swiftの仕様ではコンパイルで固めていたと記憶していますが……仕様が変わったのでしょうか？こちらは、推測が相当程度含まれているので、ソースはお示しできません。ソース根拠の要求にお応えできず申し訳ありません。
https://www.apple.com/jp/swift/
MacとiOSの場合は、周辺機器の拡張に関する制御系に差があることは見なくても分かります。
そのため、一部のシステムサービスはMacOSにはあってもiOSにないことが予想されます。同様にiOSには搭載して、MacOSではオプショナルな機能もあるでしょう。タッチインタフェースとか……。そういう部分を考えれば、Apple A GPU独自拡張を追加してSwiftのコンパイラで隠蔽を掛けていれば、GPUの性能を他社GPU以上に引き上げることも出来るでしょう。
この辺りを私は関数の差と丸めてしまっています。ここに誤解があったのであればお詫び致します。また間違いがあるようなら、情報をいただければ修正致します。なお、実行アプリケーションソフトの性能では関係ないからこんな記事は関係ないという話なら、そうかもしれません。
「あと、metalで処理が早くなるのはほんの一部で他の性能はOpenGLと変わりません。どうせプログラマーでもないあなたがよくもまあこんな知ったかぶった痛い記事かけますねwww 」
そうですね。私はPGではありません。その通りです。痛いのは自覚していますし、コードの書き方に大きな差違はないのも知っております。その点は認めますし、質問者様がPGなら質問者様の方が詳しいところも多いと思います。
ただ、知ったかぶりで痛くても、ここは私の書いている個人Blogなので書くのは自由だとも思っています。これだけは余計なお世話です。
それから、私が囓った言語はスクリプトも含めると、本を買って勉強した物も含めて、
BAISC
Visual Basic、
C言語
COBOL
ActivePerl、
HTML4～、
WSH/VBS、
PowerShell、
Windows CMD、
UNIX（Solaris）/Linux（Turbo/RHEL）向けのスクリプト。
この中でCOBOLは読んで僅かに修正できる程度のデバッグのみです。殆ど、コマンドスクリプトみたないレベルで主にPC系（Windows/MS-DOS/それ以前）なので、化石みたいなものですし、PG（プログラマー）ではありませんし、SEとCE、OPの間のような仕事をしてきたので、広く浅い知識で、１から設計したのは２～３しかありません。いずれも業務用の管理ウェアでチープなものです。PGについて記事を書いてくれと言われても、洗練されておらず癖が強いので、無理です。しかもセンスがないので、これを作ると決めてから完成するまで他の人より日数が掛かるので……好きでも人にコードの書き方を教えたりは出来ないのです。だから本格的なPG設計をしている方は尊敬します。
また、画面制御系はあまり行うことがなく、どちらかというと組織企業向けで仕事をしてきましたので、認識の誤りがいくつもあるのかもしれません。こういうのが好きなので、コアな設計書や仕様書は読んで勉強していますが、全部を理解することも出来ません。そんなレベルですが、もし、間違いがあるなら、笑うのではなく、教えていただければありがたいと思います。
私のスタンスは、基本的にハードウェアの基本性能ありきなので、コード書きから見てどうかではないことをご留意いただければと思います。
それから、最後に大事なことなので、もう一度書いておきますが、Blogで自分の記事を書くのは自由です。PGじゃなから、記事は書くなとか、専門家しか記事を書いてはいけないという世の中になるようでは、自由な主張が出来る社会は終わります。プログラマーはハードのことなんて知らないんだから、ハードのことなど書くなと言われるのと同じです。電気屋さんで働いていないと、掃除機の比較はしちゃいけない？とか？そういう話になるかもしれません。
私が、匿名様とコメントを交わせるのも、匿名様が私にコメントが出来るのも、この記事があってこその縁であると思います。そこから、私自身も学び、匿名様も私のことをご理解していただけるかも知れない。
それだけでも、この記事には意味があります。
これを機会に、当ブログに足を運んでいただければ、嬉しいのですが、
腹が立つ記事しかない馬鹿にするしかないと思われるなら、当ブログに足を運び記事を読むのは、避けていただければと思います。記事を馬鹿にされると、私もいい気はしませんので、あまり繰り返されるなら、相応の対応をせざる終えなくなります。
もし、今後も足を運んで下さるなら、出来れば馬鹿にして笑うのではなく、ご意見としてここの見解がおかしいのではないかとか、そういう建設的な形で書いていただければ幸いです。私自身間違いもありますし、後から見て、自分でも赤面するような記事もありますから。Blogを辞めない限り消さないけど……。あと、出来れば極端に古い記事は修正が大変なので……指摘されても、指摘をそのまま置いて放置するか、本文対応しないかもしれません。（記事アクセス数次第です）
匿名様
再コメントありがとうございます。悪い方でなくてよかった。
私の方こそ、拙い内容で申し訳ない限りです。
匿名様の内容を読む限り、知識ベースと互いが主張している内容が違うように見え、匿名様の考え方も正しいと思われます。
匿名様は常に書いたコードの範疇でどう動くかを見ておられるようです。実効性能をプログラミングした結果の挙動だけで考えて見るとそれで正解です。PGにも差も無いのだから、むしろ私の解釈がおかしく見えるのでしょう。
私は、コードをOSで実行する際に、どんな経路を辿りハードウェアに到達するか？そのハードの仕様がどの程度の物かを基にしてOSの仕組みとしてどうなのかを書いています。ネイティブというのを使ったのは、OS毎の抽象化レベルが違うという説明に繋がるだろうと単純に思って使ったのですが、常に動かすアプリケーション目線で捉えられているようなので、これでは説明になっていないと気が付きました。
この記事のタイトルを原点にもう一度書いておきます。
この記事はハード一つ一つの部品における物理性能を基にすると、PC側とスマホ側の数字が合わないという前提があり、それを考えて書いた記事です。その中に専用命令という部分があって、そこに目を奪われているのだと思います。ソースコード上の差がなければ、専用命令は追加されていないのではないかと。その辺りも含めて全部書きます。そこに認識の差があるようです。
まず、
>TFLOPSがGPUの素の性能と見るのはナンセンスです。
その通りですが、ではどこで差が出るのでしょうか？それを説明しなければいけません。
それを説明できなければ、アプリケーションとしての性能で、約2倍高効率というケースもあるという結論になってしまいます。
例えばGPU性能、1TFlops（1000GFlops）と500GFlopsなのに同じゲーム（OSは異なりプログラミングに使ったコードはほぼ同じ）を実行すると、ほぼ同じ描画性能なのかという場合、何で性能差を示すのか？考えてください。
これは、ハードウェアオタクじゃ無ければ理解出来ないかも知れませんが、
ROPか？それとも、Shader Modelか、ビデオメモリーや帯域幅か？ドライバーか？コアクロックか？このうち、コアクロックは浮動小数点演算の性能差になるため、除外しなければなりません。ビデオメモリーや帯域幅だけでは同じ解像度時のコアの絶対性能は上がらないため、これも多少は影響しますがベンチでは大きくはないでしょう。ROPの数はメモリー出力の並列性を高めますが、これも解像度に対してのみ有効です。この中で、唯一純粋に全体のゲーミング描画に影響を与えるのは、Shader Model等命令セットの追加です。
この記事はタイトルにあるように、命令セットが追加されてそれをコンパイラ側で自動認識して隠蔽している可能性がなければ、その差を埋められないと考えたものです。
ただ、iOSは周辺機器やアプリの差からカーネル切替時間が違うはずなので、それをさらに突き詰めて改善した可能性もありえます。実際、そうコメントされたら、それに、その可能性もあると同意を示さざる終えなかったと言えます。
尚、コード書き（PG）側から見た何かが変わる訳ではありません。（変わらないことがある理由は後述します）「GPU性能はMacBook Pro相当」という部分において、GPUの純粋性能はMacBookの方が上で、効率はiOSが上ということだけなのです。
この効率を変えているのは、アーキテクチャの差とOSの処理方法です。この辺りは、プリエンティブマルチタスクのカーネル制御時間の制御などを調べていただければと思います。OSの種別が変わると、制御時間や方法は変わります。ただ、OSが変わるとその差をこことここが違うから、時間が何ミリ秒違うと説明することは出来ません。
処理目的などに合わせて、構造が異なるため、単純比較は出来ないのです。
これを、最も分かり易い例で言えば、ゲーミングOS（Playstation OSなど）でしょう。
これは、GPUやCPUの性能はPCより低いのですが、PCに近い質感を実現できます。これは、周辺機器が限定されていたり、表（フォアグラウンド）や裏（バックグラウンド）で動くアプリケーションの数が決まっていると、VM（アプリケーションを動かす仮想実行環境）切替を監視する工程が不要になるため、CPUやGPUの処理効率が大幅に上がるという特徴から生まれる差によるものです。
他にも、HPCの京速コンピュータ「京」のノード実行効率などもそういう部分を突き詰めた結果、コンパイラの仕組みを最適化し分散処理の効率を大幅に上げているのです。
PCが、例えMetalのような機能を使っても、ゲーミングOSと同じ性能が発揮できないのは、カーネルが管理する割り込み（方法、時間、受け渡し手順等）や監視の数に差があるからです。
その割り込みが、ミリ秒以下でぱっと見た時に見かけの差が見えなくても、数が多ければ、速度に影響を与えます。特にGPUのような膨大な並列数と演算数を持つ回路とのやりとりはそれがかなり大きくなり、CPUもコア数が増えサービスが増えている昨今では馬鹿になりません。これが、iOSとmacOSの差になります。
ただ、これだけではちょっと足りないように見えたのです。
スマホのような電力効率を求めるモバイルプラットフォームの製品は、消費電力の効率も大事です。何か命令を追加しているものの、実際にコードを書くときに差は見えないという可能性がないと、熱効率や電力効率が悪化しますから、SoCプロセスノードとの兼ね合いを見ると、専用命令を増やした方が効率的です。
では、命令セットを増やしたなら、命令セット分の新しいコード記述が増えるのではないかと思われるでしょう。しかし、それも実は必ず増える訳ではありません。
これは、Intel AVXやAVX2、Hardware T&LのSSE置き換え、HLSLの世代交代などで、同じコードのまま新コンパイラを使えば、一部を新命令に振り替え、加速するというコンパイラやハードウェア機能もあります。置き換えや振り替えは珍しいことではないのです。そういうレベルの変更なら、コードを書いているユーザー（プログラマー）にこのように書きなさいと示す必要もありません。そして、ハードやドライバ（OS）の世代が対応したものに変わり、コンパイラの世代が変わるとそれが機能するようになります。
尚、Andorid Run Timeの構造差とiOSのネイティブ実行の差という言い回しは、iOSはハードウェアを固定しているため、Android Run Timeの仮想マシンほど仮想化時オーバーヘッドがないという前提を説明するために書いたものです。Androidはx86とArm（ArmでもSnapdragon 、Helio、Kirin）といった、各種プラットフォームとさらに、様々な周辺機器とのやりとりを想定しており、その際にコンパイル済みのコードをインストールすると、実行環境が複雑化してしまう（重たくなったり、セキュリティ上の脆弱性になる）という欠点があったのです。
そこで、JIT/AOTではハードウェアの仕様に合わせて、インストールまたは実行時にその環境に最適かされた形でコンパイルを行う仕組みを取りました。そして、実行環境は、Android VMで割り込み範囲等もインストールで指定した範囲に留めるように最初に決めおくことで、オーバーヘッド性能の低下（不要な割り込みを最初から除外する）を抑え、アプリケーションによるセキュリティ寝食も起きないように分離したのです。
そうすることで、ハードの差もVMが吸収してくれるため、互換性の問題も減らせ、性能もハードウェアに合わせて最大になるように最適化されます。
それでも、iOSよりハードの種類が多く、全体に対応させるとどうしてもコードが増え、さらに仮想マシンのボトルネックは必ず出てきます。Androidの根幹となるシステムは迂回コードがカーネルやサービスに多くありますので。そこが、高度連続実行時の性能におけるボトルネックになる訳です。だから、iOS並の実効性能を得るには、パワフルなプロセッサが必要になります。
このAndroid で使うVMの仕組みに繋がるART（Android Run time）はiOSにはありません。ARTはRuntimeですから、いわゆる関数群であり、その仕組みはiOSにはありません。このARTは開発者から見て特別な何かではありません。そもそも、ARTは実行環境そのものですから。ただ、ARTの仕組みはiOSより複雑でオーバーヘッドが大きいのです。それを、JIT/AOTという構造で可能な限り減らしている訳です。
iOSやMacOSの場合は、Darwin（NeXTSTEP）がカーネル管理をしていますが、ハードウェア開発が一本なので、ARTのような構造は不要なのです。どちらかというと、ゲームOSのように設計できます。何故なら、ハードウェアはApple製品しか無く、周辺機器もアプリも基本Appleが認めたもののみになります。その分、障壁が軽く、ARTと比べると実行系統は殆どネイティブで実行されます。セキュリティはAppStore側の認証を厳しくすることで担保しているのも、これの特徴です。
この部分で、説明が足りなかったのがたぶん不味かったのだと思います。
これで、全ての説明になっているかな？
なっていなかったらごめんなさい。力不足です。
＜匿名様＞
こちらこそ、大してアクセス数もない記事にわざわざお付き合いしていただいて申し訳ない限りです。
改めてこちらのデータを再調査した結果でお知らせします。
実は、前の追加を書いた後に私側も本当に大丈夫なのかと電卓を弾いたり、ベース資料や発表資料などを調べていました。当該記事を書いた時にも、可能性はあるけど、まさかと思いながら書いていたのが情けない。ハッ、こういう大丈夫だろうとか、間違っていないだろうというのが、特殊詐欺被害に遭う人のタイプなのかも？などとも思いながら。
全体を調べ直した結果、当方に根本的なミスがありました。Intel GPUの計算値を誤っていたようで、上記のiPhone7のものと同じで、820～870GFlops(FP16）の半精度で計算していたという……こんな記事まで書いているのに恥です。一方で、A11比、～1.5倍で換算すると、FP32で最大624～672.75GFlops（もう少し誤差があるのですけど）でした。
これは、こちらの全面的な凡ミスであると言わざる終えません。
計算から逆算すると、Intel GPUやCPUの方が効率は良いということになりました。
尚この記事は削除すると、既に閲覧した人が再閲覧で参考にされるときに、誤っていることを識別出来ない恐れがあるため、恥ずかしい内容ですけど、掲載は継続致します。もし、匿名様のコメント削除をご希望の場合は、コメントにてお知らせいただければ、コメントについては削除致します。
長い時間を掛けて、当方のミスにお付き合いいただき、そしてご指摘いただき本当にありがとうございました。
閲覧された方々にも間違いを掲載したことにつきまして、お詫び申し上げます。
それから、差し支えなければで良いのですが、今後のために一つ確認させてください。
>iPhone7の時点で約500GFLOPSほどあるので
という数値はどういう情報を基にした計算なのかを教えていただけないでしょうか？私の調べた範囲では、iPhone 7のGT7600PlusのFP32は310～345GFlops（FP32換算）になり、500GFlopsを超えるとしたらFP16（半精度演算）で、その倍数未満になるのではないかなと思うので、出来れば確認いただけると幸いです。
iPhone X Xs Max XR 8 7 6 6s Plus ガラスフィルム iPhoneXSMax iPhoneXS 保護フィルム iPhone 5 5s 5C SE 強化ガラスフィルム ガラス Xperia Z5 Z4 Z3 compact SO01H SO02H SO03H SO03G SO02G SO01G 強化ガラス フィルム P9 lite honor8 9H 画面 飛散防止
保護フィルムのColorful
商品説明 商品名 ガラスフィルム 素材 強化ガラス セット内容 ガラスフィルム 1枚 クリーナクロス
楽天市場
保護フィルムのColorful
商品説明 商品名 ガラスフィルム 素材 強化ガラス セット内容 ガラスフィルム 1枚 クリーナクロス
楽天市場
この記事へのコメント
まあわたしはjavaしか分かりませんが。
GPU性能がAppleの方が2倍効率がいいという点についてですが、TFLOPSがGPUの素の性能と見るのはナンセンスです。
GPU性能がAppleの方が2倍効率がいいという点についてですが、TFLOPSがGPUの素の性能と見るのはナンセンスです。
>グラフを見ると分かるように，Atom Z3480搭載リファレンス機は，iPhone 5sよりも高性能で，GALAXY S4にはやや及ばないという程度の結果となっていた。Apple A7のグラフィックスコアは，PowerVR G6430であり，Atom Z3400が搭載するG6400より上位のGPUコアである。
https://www.4gamer.net/games/047/G004743/20140224028/
参考になればと思います。