全MacがArmに切り替えか まずはiMacと13インチMacBook Proから …… ウィンテル時代からの決別。

ITmediaの記事である。CPUアーキテクチャの刷新はこれで3度目である。


Intel Macも約15年で終わることになりそうだという記事である。Power系も13~14年ほどだった。その前はMC68000系だったが、いずれも時代の流れで廃れてきた。今回はIntelの不甲斐なさが招いた話だが、Intelに比べて数量の安定に関する問題と、スタンバイ時の発熱問題を持つAMDに移行するのも難しいため、自社へと移行することになった。

元々、Appleは自社開発のOSを持つので、プラットフォーム移行しやすいが、その一方で過去の互換性切り捨てが起きやすいのが玉に瑕であり、一部のMacでWindowsを使っているユーザーは戦々恐々としているかもしれない。
この先、Boot CampによるWindowsの提供が続くのかや、Arm On Windowsになるとしたら、それでx64サポートが行われる見込みがあるのか、その性能がどの程度落ちるかも注目点となる。もしかすると、Boot Campが廃止されるという可能性も無きにしも非ずである。


<Intel凋落とAppleの成長>

尚、Appleが自社開発に転じたのは、明らかにIntelのプロセスノード問題によって消費電力を落としたり、コストを削減することが出来なくなったことが原因だろう。Intelの現状を見ると、それが打開できる目処も今のところ立っていないことが分かる。Lakefieldは製造量が少ないようで、Appleが数量を確保するのは難しいと思われるし、Ice Lake(10nm)も数量は少なく、Comet Lake(14nm)の方が量が多い。Comet Lakeはクロックが少し高いものがあるだけでCoffee Lakeとほぼ同じである。一方でクロックが上がると大きくTDPが上がるという問題が既に生じ始めている。

Tiger LakeもIce Lakeよりは増えるだろうが、概ねそうなると予想され、Rocket Lake(14nm)がデスクトップなどではメインになると予想される。

AppleにとってはIntelだから有利だったはずのものが既に無くなってきているわけで、Boot Campの問題などが解消されるか、利用者が減っていて切り捨てても良いと判断したなら、Apple AプロセッサーというArmに置き換えるのは理に適っている。Armでもコア数を増やすか、概ねAppleのために策定されたと思われるCortex-Xでベクター系の命令を強化していけば、かなり性能は上がると考えられる。AppleのOSはクローズド故にゲーム機並にボトルネックが出ないように中間処理が少なく出来ているのもAppleにとっては強みとなる。

また、Apple自身も既にWindowsなどに媚びを売る理由がないというのも大きなポイントかも知れない。Appleは00年代の初頭こそ苦しい時代だったが、MacOS X(10.0)の登場からiPod、iPhone、iPad、Apple Watchと立て続けのヒットを遂げたこと、さらに現在はサブスクリプションやクラウドサービスの拡充で、ハードに拘らない状況を作ったことで、これらに媚びる理由もない。

MicrosoftもMacに合わせてシェアを取りに行くのか?それとも、対応を諦めるかはマ社次第だ。むしろ、マ社が合わせていかないといけない状況へと立場が逆転した。そう考えると、Appleは20年ほどでウィンテルという巨大なIT業界の覇者の存亡を左右するまでに大きく育ったことを意味している。

即ち、もうウィンテルに拘る理由がAppleにはないのだ。

この先、Appleは昔のような独自路線に再び戻る訳だが、これが続くのかは……予測が付かない。まあ、今までのAppleの傾向を見ると14~15年のサイクルプラットフォームは維持されてきた。即ち、過去を踏襲するなら2035年頃までは戻ってくることも、他のアーキテクチャに変わることもないだろう。まあ、今心配されるのは、売上げこそ良いものの未来をみるとIntelの状況が決して順風には見えないことだ。Tiger Lake移行で一気に復活するなら良いが、Appleという安定した顧客が逃げていくというのは、かなりIntelにとって痛い話だろう。


なすさま

コメントありがとうございます。

>Intelプロセッサの性能がそこまで問題とも思えていないのですが

これは、Appleから見てだったり、求める消費者のニーズの未来などを考えると、今のSunny Coveの10nm技術を引き摺るとIntelは楽ではないでしょう。まあ、ファウンドリーとしてTMSCなどを使う他のメーカーと違って、Intelは生産力、生産量が多く、設計から生産まで全て自社で出来るという強みがあるので、すぐには落ちないでしょうけど、x86でも低電圧プロセッサーでAMDが本格的に優れた製品を投入できるようになれば、厳しくなるかもしれません。まあ、それでも今特別新しい性能を求めることをPCでやらないなら、性能なんてCore i3でもCeleronでも足りますけど……。

それでは、Appleには新しい挑戦が出来ないと言うことでもあるのだと思います。
私もそういう点では楽しみです。

通りすがりさま

>intelからしてもappleの売り上げは5%程度であまり痛手ではないようですしお互い頃合いかなと思います

今やIntelもデスクトップよりモバイル、ワークステーション/小規模サーバーより大規模データセンターですからね。一方でAppleはスマホとタブレットが主軸ですから、確かにそろそろお別れの時期として良かったのかも知れませんね。

めるさま

>そもそもCPUで処理するプログラムはネイティブコードなら中間処理もなくそのまま走りますよ?

ご指摘ありがとうございます。
私の書き方が悪いのでしょうけど、はい、理解しています……AppleのOSの話とプログラムの話なので話が合わないのだと信じていますが、一応、OSの中間処理について書いておきます。

まず、自分以外が作ったものを除く、あるOS(MacとかWindowsとかAndroidとかiOSなど)向けに開発されたアプリケーションソフトウェアで、OS側でアプリケーションの挙動を制御しているなら、抽象化は必ずどこかにある「はず」です。全くゼロというのは通常は有り得ません。
ないとしたらシングルタスクOSで且つ、OSカーネルで制御管理をせず、API libraryを使っていない軽量の組込OSでしょう。この場合は、フルネイティブで書かれている可能性があります。

ただ、その抽象化があったとしても、なかったとしても、そのOSを使っている人がそれを自覚することはありません。何故なら、その抽象化によって落ちている性能は、そのOSを使う以上は必ず生じる物であり、その差を示す証拠はそのOSで使っている間はどうやっても出せないからです。だから、抽象化のレベルを図るには他のOSで同じようなソフトウェアを作ってはかることになるわけです。

そもそも、OS内抽象化の話では、一部(表向き)のコード記述のどうこうは関係なく全般の話であるという点も問題となります。ここが今回、めるさまが指摘された点と、私が書いている点の相違点(誤解された点)であると思われます。過去にもこういう指摘を受ける度にその都度書いていますけど。
(その都度、その人向けに説明を書いています。ここの解釈はプログラミングする人やハードウェアの知識の差によってネイティブの幅が変わることもあり、意見を一致されるのが難しいようです。)

ネイティブならそのまま走るのは当たり前です。ただ、OSに依存するアプリケーションで完全なネイティブで記述しているなら、Arm版Macで本当に動くのかは解りません。いや、完全ネイティブならMac依存せず、OSがなくても下手をすれば動くでしょう(MacとWindowsだとプラットフォームの根本にあるファームウェアUEFI/BIOSの仕様が異なるはずなのでそれだけでは動きませんけど)。

重要なので何度も書きますが、一部のコードがネイティブであるのと、アプリケーション(ソフトウェア)全体を通じてネイティブなのは別です。通常、WindowsやMac専用、対応のソフトウェアには100%完全ネイティブのアプリはありません。一部のコードにネイティブ(直接ハードウェアに指示出しするコード)が含まれる程度です。CPUにしてもGPUにしてもですよ。

MS-DOS時代なら抽象化は殆どありませんでしたけど、それでもDOSのSysを利用して出力と入力をCPU、グラフィックス、HIDの間で制御していました。

ネイティブだけで動くならOSもドライバーも要りません。常時演算で画面出力とかせずにALUやFPU、SIMDに直接和佐積算をさせるとかなら、いわゆるデータセンターやHPCのようにホストコンソール画面がないものだとそういう用途に近いものもあるので、CPUオンリーの処理は出来るかも知れません。(が、通常はそれでもカーネルとAPIへの最適化は行います。CPUノードが複数ある場合はその考慮も必要です。)

そうでなければ、MacにしてもWindowsにしてもAndroidにしてもCPU向けの中間処理は多々あります。Macの場合はSwiftで作成したコードをコンパイルする際に、Darwinで安定制御するパラを加え、処理する際にDarwin上のkernelがcocoaやOpenGL/CLで利用しているAPIがあるかどうかを振り分けた上で、処理をGPUとCPU(コアのうちどれに命令を送るかなど)またはそれ以外の処理系のいずれに命令を回すかを決めているはずで、それが中間処理となります。これがないなら、完全にOS範囲外のプログラムとなります。いわゆるノラOSだったり、脱獄(jailbreak)です。

MacのアプリがWindowsで動かない、WindowsのアプリがMacで動かないのは、この工程が違うからであり、この工程が違う中で、OSの上で動かすというメリットを利用して、一部の当たり前の処理を自分で記述しなくても動くようにパッケージ化(API群の関数に統合しそれは自動的にコンパイル時にモジュールとして提供されるような仕組みに)してかき消しているのが、今のOSです。だから、一見、ネイティブのコードだけで書いていたつもりでも、実はネイティブではないのです。そこがOSの違いによって生まれるオーバーヘッドになります。

逆に言えば、だからこそネイティブだと思っているソフトウェアでも、このオーバーヘッドは必ずありますし、OSの仕様が変わると互換性の問題が出ることがある理由もここにあります。それらも全部自分で設計出来るなら、自分が設計した範囲までしかオーバーヘッドはありませんので、ないと思えばなくなるでしょう。そして、そういうアプリケーションは当然ですがOSに依存しませんので、ディスクをセットすればそのディスクだけで起動するでしょう。その代わりカーネル代わりのスケジューラー管理なども行う必要があります。それをしないと、1コアしか使えないという可能性も出てきますし、マルチコア考慮済みでも調停切替を上手く設定出来なければ、処理は遅くなります。

という認識が必要です。尚、ブラウザアプリならOSに依存しないとか言う人もいますけど……。オブジェクト指向性とネイティブは別でもっと遠い話です。

OSに対する本来のネイティブというのは、自分が求める結果を出す出力系までOSや開発環境、開発統合環境のプリセットを使わずに自力で設計するということです。これが完全なネイティブです。そこから、どこまで抽象化しているかというのがOSの性能(パフォーマンスが高いか低いかの違い)となります。その影響を決めるのはカーネルであり、APIであり、コンパイラです。

大規模なOS(ハードウェアの種類が豊富だったり、沢山の周辺機器が使えるOS)は、多くのハードウェアで可能な限り同じようなアプリケーションが使える環境を作るため抽象化の率が高くなります。そのため、性能が落ちやすいという特徴があります。それに対して、単一の役割などに特化すると、OS側の抽象化が殆どなくても、コンパイラだけでそのコードを内包することが出来るため、ネイティブに近い性能を発揮します。だから、組込OSは遅いCPUを乗せていても、快適に動く事もあるわけです。

また、プリエンティブマルチタスク制御やバーチャル(仮想)マルチタスクをしているカーネルでは、例え、ネイティブ命令を付与していても、その優先順位をOSカーネルが支配しており、複数のアプリケーションでリソースを時事分割してリソースを切り替えています。この優先度と切替に伴うレスポンスの差もOSのパフォーマンスの優劣を決める要素になることもあります。

以上のようになります。これは、OS全体として見た時の抽象化やOSが何をどのように管理しているのかという違いの話です。
プログラミングとしてネイティブのコード記述を使っている分高速になる(APIなどの抽象化コードを使って簡略記述している場合に比べて高速)というのは、間違いではありませんが、ここでいうMacOSやiPadOS、iOS、ゲームコンソールOS、Windows、LinuxなどのOSに関するものより、もっと上のOS側がもたらす違いである点をご理解頂ければと思います。

こういう部分まで見据えて、この記事を読んで頂くと楽しいと思って頂ければ良いのですけど、何卒私は文字列を書くのが下手クソなので、難しいかもしれません。変な誤解をさせてしまい申し訳ないと思っております。


めるさま

2度も再コメントありがとうございます。

めるさまが言わんとする内容は、理解いたしました。私の中での抽象化は、CPUが制御を行うメモリーも含めた全般の処理工程(スレッドレベル)での抽象化になりますので、そこが一致しなかったのでしょう。

メルさまが言わんとしていることに対して、納得はいきました。抽象化として見ているものが違うということが分かりました。
めるさまはCPUの抽象化=大きなギャップを埋めるものという認識なのだと思われます。私はOSとしてのカーネルが作り出すアプリごとのメモリーの割当て方法も含めたもので見ているということになります。だから意見が合わなかったということだと思われます。

私の中でOSにおけるCPUの抽象化というのは、それぞれのアプリケーションに対する実行環境、VM(Virtual Machine)を作ってプロセスやスレッド空間をメモリー上それぞれに作る時点で行われているという前提となっています。これをやらないと、メモリー空間を他のプロセスで共有したり、不正なデタッチ(妨害)やアタッチ(侵入)が行えるため、これはメモリーをCPUで抽象化(仮想化)し、CPUのリソースを複数のアプリケーションでCPUを分割するという抽象化でもあります。端的に言えば、3GHzの8コアがフルに使えるように見えて、それを3つのアプリケーションで分割して使うというのが抽象化の結果です。これアプリケーションレイヤーのVMベースなので仮想化と言う人もいるでしょうけど、この仮想はアプリの実行において行われる複数の抽象化する処理工程をOSの機能として仮想としただけですから、実はCPUやメモリーも含めて抽象化されているという認識になります。

抽象化は一つの決まった形態を共通の形に体現するという意味ですから、目に見えてハードギャップがあるものとは限りません。
それだけです。パフォーマンスはこの段階で変わるため、これがOSの性能差を示すモノであると考えています。というのは、先に書いたもののOSレベルでの説明となります。これは、私がシングルタスク時代やマイコン時代からずっとコンピュータの言語形態やOSを見ていた故の見立てです。この辺りの見方は人によって変わるかもしれません。

それに対して、メルさまは「OSとは関係ないロジックが”中間処理”がなくそのまま動く」で見られているというのであり、それはその通りです。否定のしようもありません。私の場合は、抽象化そのものをカーネルやCPUが介在するメモリー空間も含めた処理の形態(主記憶と中央演算処理装置の主従関係も含めたもの)として見ていますので、意見が不一致となったのだと思われます。即ち、私の考えていたCPUの抽象化は、メルさまには抽象化では無かったということになるのだろうと思います。いわゆる抽象化の粒度と見ている方向性は人によって認識が異なるわけです。それはそれでお互いが考えている領域が違うことが分かって良いことだと思います。

私からのお願いとしては、上記のような、メルさまとは視点とは異なったということであると考えて頂ければと思います。

いかがでしょうか?

納得行かない場合は申し訳ないとは思いますが、こういう変な見立てがあるのだと思って頂ければと思います。一応一通りは書いたつもりなので、私の説明が残念なだけです。こんな説明が下手なら、もう見ないぞ~と言われても構いません。
別にこれが正しいと強要する気もありませんし、私的にはOSにおけるCPUリソースの抽象化を何と定義するかだと思うので揉める話でもないと思うのです。ただ、複数のOSの仕様解説や書籍などを見てきた中で私なりの見方がここにあって、こういう見方もあるのだと理解して頂ければ幸いです。もしかすると、他の方の記事や書籍でもそういう記事が見られることはあるかもしれませんので、その時にはいつか思い出して頂ければ、もっと嬉しいのですけど。
正直、めるさまのコメントでそう見るのか面白いなと楽しんでしまったのですけど、ヒートアップされていたならごめんなさい。
私は、違うよと言われると自分の理由を示して違いを知りたくなってしまって、ワクワクするので、何度もコメントをさせるほど、お手間とお手数をおかけして申し訳ありませんでした。そして、ありがとうございました。


最新モデル Apple MacBook Air (13インチPro, 1.1GHzデュアルコア第10世代Intel Core i3プロセッサ, 8GB RAM, 256GB) - ゴールド



ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 3

なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー)

この記事へのコメント

なす
2020年06月22日 23:13
プロセスの実際の微細化状況を考えるにIntelプロセッサの性能がそこまで問題とも思えていないのですが、
iPad Proが高性能化・高価格化して製作現場向け対応も進んでる今、MacをARMに置き換えたとして一体どうなっていくのか楽しみです。
通りすがり
2020年06月24日 03:08
appleのPCシェアは4-5位で上位3社の支配的市場なので
資産やbootcampを切り捨てても主力のiOSと親和性を活かして対抗したいし
intelからしてもappleの売り上げは5%程度であまり痛手ではないようですし
お互い頃合いかなと思います
める
2020年06月27日 11:13
> AppleのOSはクローズド故にゲーム機並にボトルネックが出ないように中間処理が少なく出来ているのもAppleにとっては強みとなる

そもそもCPUで処理するプログラムはネイティブコードなら中間処理もなくそのまま走りますよ?
める
2020年06月29日 07:48
> OS側でアプリケーションの挙動を制御しているなら、抽象化は必ずどこかにある「はず」です。

はい、その通りです。ですがそれはシステムコールやAPIを介した処理のみです。それがないプログラム、例えばベンチマークはそれがそのまま動きます。もちろん間にコンテキストスイッチ等のオーバーヘッドはありますが、そのコストはどのOSもマルチタスクをサポートするなら避けられないです。私が言いたいのはシステムコールのコストはOSが動くマシンが決まっていようとそうでなかろうと、それによってコストが変わることはないということです。
> 多くのハードウェアで可能な限り同じようなアプリケーションが使える環境を作るため抽象化の率が高くなります。そのため、性能が落ちやすいという特徴があります。それに対して、単一の役割などに特化すると、OS側の抽象化が殆どなくても、コンパイラだけでそのコードを内包することが出来るため、ネイティブに近い性能を発揮します。

OSの抽象化がそこまでなら、わざわざWindows10 on Armなんて作らなくてもいいと思うのですが。OSの役割はハードの抽象化ですが、それはあくまでCPU以外のハードのためのものであってCPUは抽象化してません(ブートローダーを除く)
> MacのアプリがWindowsで動かない、WindowsのアプリがMacで動かないのは、この工程が違うからであり、

それはAPIやシステムコールが違うだけでは?

私が言いたいのは「OSとは関係ないロジックが”中間処理”がなくそのまま動く」ということです
> また、プリエンティブマルチタスク制御やバーチャル(仮想)マルチタスクをしているカーネルでは、例え、ネイティブ命令を付与していても、その優先順位をOSカーネルが支配しており、複数のアプリケーションでリソースを時事分割してリソースを切り替えています。この優先度と切替に伴うレスポンスの差もOSのパフォーマンスの優劣を決める要素になることもあります。

はい。繰り返しになりますがこのコストはどのOSも払わなければならないので今回の話では関係ないです