Parallels がApple シリコンでx86エミュレーションをテスト中…… 起動に最大7分かかるけれど。

The Vergeの記事である。


ParalleslsがParallels Desktop 20.2.0の早期プレビュー(early Preview)でx64版のWindows 10 64bitやWIndows 11(新規作成は出来ない、移行は24H2を除く)の実行を試すテストが始まったようだ。要は、ARMでx86を完全にエミュレーションするという訳だ。

記事はこの発表分をもとに書かされているようなので、そっちを元に示すと、
条件が読むの面倒くさいほどあって、

まず一つ目

1.It's slow,Really Slow.(遅いよ、本当に遅いよ。)

と念押しした上で、4つの不具合を示している。

・Windowsの起動時間が2から7分です。OSの応答性は低くなるよ。
・1度に複数のアプリを開くなよ。まずアプリを閉じてから別のアプリを起動しろよ。
・予期しないWindowsの動作が発生したら、再起動しろよ。
・Intelベースの仮想マシンを新たに作るとき、凄く時間がかかるから覚悟しとけ。イメージが重いほど時間は長いぞ……
 (例、Fedra 40で2時間、Win ServerやWin10 21H2で20~30分)

2.Emulated Windows is limited in features(Windowsエミュレートは機能制限が含まれるよ)

・Intelプロセッサーを搭載したMacから仮想マシンを移植(インポート)すると、Win10/11 Server 2019/2022、Linux Distを実行できるよ。但し、Windows7などの古いバージョンはサポートしないよ。Linux VMは軽量のXFCEなどを使ってね。重量級のDistや古い製品は避けてよ。

・新規でWindows 10や同Server 2022のVMも作れるよ。但し、Win2019や同10 22H2の作成には問題があるから回避策を参照してね!Windows 11や2025のVMは作成出来ないよ。SSE4.2はサポートしないからそれを使うRHEL9やCentOS9 StreamはVMを作成出来ないよ。他のLinuxは作成できるけど、プロセスが非常に不安定なんだな……

・BSD(Berkeley Software Distribution) システムはサポートしないよ。
・USBデバイスはサポートしないよ。
・Windowsの更新プログラムのインストールに失敗することがあるよ。
・x64(64bit)のOSのみサポートするから、x86のOSはインストール出来ないよ。
・サポートされるvCPUは1つだけだよ。VMのCPU数は自動的に1つでインストールされるよ。
・RAMは最大8GBまでしか割り当てないよ。
・hyperVisorは使えないよ。ネストされた仮想環境も利用出来ないよ。
・BIOSモードはサポートしないよ。
・VMを新規作成したLinuxでParallesls Toolのインストールに失敗することがあるよ。

などなどである。

性能が低い理由は、現状で使えるvCPUコアが1つでかつRAMの割当てが少なく、SSE4.2サポートなどいくつかの命令セットを代替する手段がないからだと考えられる。用は、シングルコアのx86プロセッサー時代のマルチタスク性能になるので、マルチタスク前提で組まれたOSでは動きが鈍足になる上に、命令セットのいくつかをエミュレート出来ずに欠如していることで、ソフトウェア処理のオーバーヘッドが大幅に増えているのだと思われる。

それから、最新のアップデートなどを適用できないのは、セキュリティの問題と、この性能の問題の両方があるのだろう。Intel MacでParalleslsで動作するものも、Arm版では解決出来ない問題が山積みでこれから、潰す方法を考えるのだと思われる。出来るかどうかは分からないが……

元々、ハードの知的財産の問題がないと仮定した場合、x86側がARMv9などをエミュレートするのは割と出来なくはないとされる。特に、XeonやEPYC系のコアなら命令セットが充実しているのでその気があり、知的財産権(ARMライセンス)の問題がなければそこそこのエミュレートが出来るだろうと考えられる。しかし、逆だと難しくなる。

これは、ベース設計がCISCで内部的にRISCの発想で発展し命令セットを拡張して育ったx86と、元々RISCベースで必要な命令だけを選んで実装してきたRISCの差である。CISCから内部をRISC系に置き換えた現行のx86は、豊富な命令形式を持っており、ARMにない命令の多くをサポートしている。もちろんARMにしかないものもあるが、代替出来る手法は多いので、エミュレートしようと思えば出来る。

その一方で、ARM側は命令の種類や数は少ない代わりに効率を重視してきたので、x86にはあってARMにない命令が多く代替が難しい命令が沢山ある。そこをARMでやるには、命令を分解しARMに沿った命令に分散する必要がある。これで性能をなるべく落とさずに、且つなるべく小規模な(メモリーを食わない)エミュレーターで実装するには難易度が高くなるというわけだ。いつかは、出来るかも知れないがまだ結構掛かるかもしれない。


ちなみに、何故、この状態でテストをはじめたかというと、単純にオープンなフィードバックが欲しいからだと思われる。何か、壁にぶつかっているというのもあるのかもしれない。速やかに完全に不具合を潰せるなら、この段階でフィードバックは求めないだろうから、いくつか社内では目を瞑らざる終えない壁が既に生じていて、それを回避する方法を他から求めているか、回避出来ないならある程度消費者のニーズに合う範囲で妥協点を探る検証や製品に本当に出来る方法があるのかを先に調べることにしたと思われる。

ここで、成果が見つかれば製品化への道筋になり、駄目だったら製品化は何らかのブレークスルーが見つかるまで遠のくのかもしれない。