質問：ソフトウェアは本当に新しい命令セットを使用しますか？

時間が経つにつれて、ベンダーは、ラップトップ、サーバー、電話、および他の多くのデバイスを制御するプロセッサに新しい命令を追加しました 。 特定の計算サブタスクを解決する機械命令を追加することは、パイプラインを複雑にすることなく、法外な値に周波数を上げようとせずに、システム全体のパフォーマンスを向上させる良い方法です。 いくつかの古い命令と同じ操作を実行する新しい命令により、特定のタスクのパフォーマンスを繰り返し向上させることができます。

Intel Software Guard Extensions（Intel SGX）やIntel Control-flow Enforcement Technology（Intel CET）などの新しい命令も、まったく新しい機能を提供できます。







良い質問は、アーキテクチャに追加された新しい命令がエンドユーザーに到達するまでの時間です。 オペレーティングシステムと他のアプリケーションは、インストールされたプロセッサのモデルに関係なく、通常、下位互換性と実行機能を提供することを考慮して、新しい命令を利用できますか？ 何年も前、新しい命令の使用は、新しいアーキテクチャ向けにプログラムを再構築し、古いハードウェアで起動して「申し訳ありませんが、このプログラムはこのハードウェアではサポートされていません」などの出力を防ぐためのチェックを追加することで達成されました。



フルプラットフォームのWind River Simicsシミュレーターを使用して、古いハードウェアとの互換性を維持しながら、最新のソフトウェアが新しい命令をどの程度使用できるかを調べました。

実験セットアップ

ソフトウェアがさまざまなハードウェアに動的に適応する方法を見つけるために、「ジェネリックPC」プラットフォームのSimicsモデルと2つの異なるプロセッサモデルを使用しました。 （コードネームはSkylake、2015年半ばにリリース）。



上記の構成で実行される次のLinux起動スクリプトを調査しました。

• Ubuntu 16.04、カーネルバージョン4.4、リリース年2016、
• Yocto 1.8、カーネルバージョン3.14、リリース2014年、
• 2.6.39カーネルのBusybox、2011年製造年。

テストには同じディスクイメージが使用されたため、ソフトウェアスタックは変更されません。 仮想プラットフォームのプロセッサ構成のみが異なっていました。 新しいハードウェアで実行されているLinuxは、新しい命令を使用することが期待されていました。 各構成は、インストルメンテーションメカニズムを接続して起動され、各命令が実行された回数をカウントしました。 Simicsの既存のインストルメンテーションメカニズムは、ゲストアプリケーションの動作を変更せず、プロセッサコマンドレベルで動作するという事実により、オペレーティングシステムのBIOSとカーネルのロードを調査できます。 同時に、実行中のアプリケーションは、インストルメンテーションを使用して起動するかどうかを判断できません。 各構成は、60秒間の仮想時間で実行されました。 BIOSとオペレーティングシステムを起動するにはこれで十分です。 各起動後、100の最も頻繁に使用される命令が選択され、さらに分析するために使用されました。

プロセッサ識別の基礎を学ぶ

この作業の基礎は、使用する機器に応じてソフトウェアが実行可能コードを動的に適応できるという前提にあります。 つまり、同じバイナリ構造では、異なる機器で異なる命令を使用できます。



このような動的な適応がどのように機能するかを理解するには、鉄がどのように機能するかを理解する必要があります。 過去に、プロセッサがほとんどなく、新しいモデルがめったに登場しない場合、ソフトウェアはパフォーマンスがIntel 80386または80486、Motorola 68020または68030であるかどうかを簡単に確認し、それに応じて動作を調整できました。 現在、非常に多様なシステムがあります。 IA-32プロセッサーの識別問題を解決するには、CPUID命令を使用します 。これは、機器のさまざまな側面を記述する複雑なシステムです。



おそらく、CPUID命令を使用して取得した情報は、そのソースについても考えずにすでに満たしているでしょう。 たとえば、Microsoft Windows 8.1のタスクマネージャーには、CPUID命令を使用して取得されたプロセッサーのタイプおよびその他の特性に関する情報が表示されます。







Linuxでは、「cat / proc / cpuinfo」コマンドを使用して、現在のシステムで使用可能なコマンドセット拡張機能のフラグなど、包括的なプロセッサー情報を表示できます。 各拡張機能には独自のフラグがあり、ソフトウェアは実行を開始する前にそのフラグを確認する必要があります。 第4世代Intel Core i5プロセッサーで収集される情報の例を次に示します。







CPUIDは、プロセッサで利用可能なさまざまな命令セット拡張に関する情報を提供しますが、ソフトウェアは、これらのフラグを実際に使用して、ハードウェアに応じて適切なバイナリコードを選択しますか？ 非標準命令を使用するすべての場所にif-then-else構造を適用するのは賢明ではありません。 これらの特性はセッション中に変更されないため、一度だけチェックすれば十分です。



Linuxは通常、異なる機能を使用して同じ機能を実装する関数ポインターを使用します。 良い例は、ファイルarch / x86 / crypto / sha1_ssse3_glue.c （source elixir.free-electrons.com/linux/v4.13.5/source ）にあります：







これらの関数は特定の機能をチェックし、対応するハッシュ関数を登録します。 呼び出しの順序により、最も効率的な実装が使用されます。 具体的には、この場合、最良のソリューションはSHA-NI拡張命令に基づいていますが、それらが利用できない場合は、AVXまたはSSE実装が使用されます。

結果

以下のグラフは、6つの異なる構成（2つのプロセッサと3つのオペレーティングシステム）を起動した結果を示しています。 すべての命令が表示され、その数は実行の合計数の1％を超えます。 「V1」とは、Core i7モデルの第1世代、「v6」（6番目）の発売を意味します。







それ自体を示唆する最初の結論：ほとんどの指示はそれほど新しいものではありません。 むしろ、それらはIntel 8086に追加された基本的な命令、つまり移動、比較、ジャンプ、追加に関連しています。 新しい命令については、それらが追加された拡張機能の名前が括弧内に書かれています。 最も頻繁に使用される28のリストには、たった6つの新しい命令しかありません。



明らかに、異なるプロセッサの使用に起因する変動に加えて、Linuxの異なるバージョン間で変動があります。 たとえば、古いカーネルで構成されたBusyBoxは、他のバージョンのカーネルでは一般的ではないLEAVE命令を使用し、POP命令をはるかに少なく使用します。 ただし、これは、新しい命令が使用可能な場合にソフトウェアがどのように使用するかという質問には答えません。 私たちの目的にとって、最も興味深いバリエーションは、同じソフトウェアスタックを起動するときのプロセッサの世代の変化によって引き起こされます。



この作業で調査したすべてのシナリオは、Linuxオペレーティングシステムにさまざまなカーネルパラメーターを読み込んでいます。 さらに、さまざまなフラグを使用して、さまざまなバージョンのコンパイラでさまざまなディストリビューションをコンパイルできます。 したがって、同じソースを使用してコンパイルされたバイナリコードでも異なる場合があります。



Yoctoの例では、この効果が見られます。 Yoctoは、ADCX、ADOX、およびMULX命令（ADXおよびBMI2拡張に含まれる）を使用します。 この例は、ソフトウェアに新しい命令が表示される速度もよく示しています。 これらの3つの命令は、Yoctoで使用されているLinuxカーネルとほぼ同時にリリースされた第5世代Intel Coreプロセッサーに追加されました。 つまり、新しい命令のサポートは、プロセッサが市場に登場したときに追加されました。 新しい命令の仕様は多くの場合、ハードウェアの実装よりも前に公開されるため、これは驚くことではありません。 つまり、ソフトウェアは新しいハードウェアに動作を事前に適合させることができます（このトピックに関する興味深い記事 ）。多くの場合、デバッグとテストに仮想プラットフォームを使用します。



ただし、新しいカーネルを搭載したUbuntu 16.04はADXとBMI2を使用しません。これは、構成が異なることを示唆しています。 おそらくこれは、コンパイラのバージョンまたはフラグ、カーネルパラメータ、またはインストールされたパッケージのセットが原因です。

制御フローの変更

興味深いのは、制御フローを変更するためにどの命令が使用されるかということです。 ヘネシーとパターソンによる同様に古典的な本で説明されている古典的な規則は、6番目の命令ごとにジャンプであると述べています。 ただし、測定では、5つの命令のうち約1つが制御フローを変更する命令であることが示されました。 Yoctoの6つのうちの1つに近い。

ベクター命令

おそらく最も広く知られている命令セット拡張機能は、 単一命令複数データ（SIMD） 、つまり、ベクトル命令です。 ベクター命令はIA-32プロセッサー上に存在し、1997年にIntel Pentiumに追加されたMMX拡張から始まります。 現在、MMX命令は事実上保証されています。 それらのいくつかは、最も一般的な指示のチャートに存在することに気付くかもしれません。 さらに、多くの異なるストリーミングSIMD拡張命令（SSE）命令と最新のAVX、AVX2、AVX512が追加されました。



オペレーティングシステムとBIOSの読み込みを勉強したことを考えると、多くのベクトル命令を期待していませんでした。 ただし、実行された命令の約5〜6％がベクトルであることが判明しました。 実行された命令の総数に対する割合として測定され、拡張によってグループ化された、実行されたベクトル命令の数：







あなたの目を引く最初のもの-Busyboxは実際にはベクトル命令を使用しません。 次に興味深い観察結果は、第1世代のプロセッサを第6プロセッサに変更すると、古い命令の数が減り、新しい命令の数が増えるということです。 特に、古いSSE命令を新しいAVXおよびAVX2に置き換えることがトレースされています。

Simics

当初、Simicsを使用してこの研究を実施することは難しくありませんでした。 明らかに、Simicsはシミュレートされたシステムのすべてのプロセッサで実行されているすべての命令にアクセスできます（これらの実験はデュアルコアシステムで実行されましたが、2番目のコアはブート時に命令を実行しませんでした）。 スクリプトは完全に自動化されており、OSがインストールされているデバイスの選択、ダウンロードの最後でのユーザー名とパスワードの入力が含まれます。 繰り返し起動するとまったく同じ結果が表示されるため、各スクリプトは1回実行されました（同じ場所から繰り返しスクリプトを検討します）。

おわりに

ソフトウェアスタックが新しいプロセッサでどのように適応し、新しい命令を使用するかを学ぶことは有益でした。 最新のプログラムは適応型であり、再コンパイルせずに使用される機器に応じて異なるコードを実行します。 検討したすべてのシナリオで、同じソフトウェアスタックが異なるシミュレーションシステムで使用され、可用性に応じて異なる命令が使用されました。 この調査は、シミュレーションで簡単に取得できるが、実際の機器ではほとんど収集できないデータの優れた例です。