スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« AVX2命令ではシフトが便利 | トップページ | 並列演算処理の微調整 »

コンパイラのAVX2生成

今は、Edax4.4のAVX2版のFFO性能が高かったので、MasterReversiについても、AVX2命令の使用等により高速化しているのだが、昨日書いた様に、AVX2命令を使うとビットボードを使うリバーシプログラムでは高速なコードを書けるのだが、通常コードも高速化される。

そのPCにAVX2命令が存在するかどうかは、__cpuidex命令で判定可能だ。

なので、配布パッケージに複数のバイナリを同梱したくない作者としては、最初、AVX2命令は、上記によりAVX2命令が実行可能と判定されたPC上でのみ、利用する様にコーディングしていた訳だ。

つまり、AVX2命令が使えるPCでのみ、新しく作成したAVX2命令を使う処理コードが呼び出される様にしていた訳なのだが、それとは別に、開発環境である所のVisual Studio Community 2017では、プロジェクトのプロパティにある「C/C++」-「コード生成」で、「拡張命令セットを有効にする」、というオプションも指定できる。

で、このオプションでAVX2を指定すると、コンパイラが随所でAVX2命令を使う様になってしまうので、AVX2命令が使えないPCでも動作するバイナリは作成できなくなる訳だ。

なので、作者的には、最初、このオプションは「設定なし」にしておいたのだが、試しに、AVX2命令を使わせる格好にしてみると、それだけで、かなり、高速化された訳だ。

更に言えば、CPUがHaswell世代でAVX2命令が普通に動作する筈のMac mini Late2014では、このオプションを指定しないでAVX2命令を使ったコードを動作させると、AVX2命令を使わない従来コードを動作させた場合よりも処理速度が大幅に低下してしまった。

ただし、コンパイラの上記オプションを指定した場合には、自前のAVX2コードを動作させない場合よりも動作させた方が高速に動作している。

と、いう事で、作者的には、コンパイラにAVX2命令を使わせるオプションを指定しない場合、イントリンシックでAVX2命令を記述している作者のコードはSSE2命令なんかでエミュレートされるのかなあ、と、思ったりもしたのだが、少なくとも、アセンブラ出力させてコード内容を見てみた所では、コンパイラにAVX2命令を使わせない設定をしている状況でも、イントリンシックで記述したコードについては、AVX2命令が使われていた。

実際、AVX2命令が動作しないPCで、自前AVX2命令を強制的に動作させる格好でテストしてみると、コンパイラにAVX2命令を使わせない設定を行っていても、プログラムを動作させるとクラッシュしてしまった。

と、いう事で、詳細については調べ切れていないのだが、イントリンシックで自前のAVX2命令を使っているにも関わらず、コンパイラにAVX2命令を使わせる設定を行っていない場合には、多分、通常処理コードとイントリンシックとのデータのやりとり等で大幅なオーバーヘッドが発生する事になるのかもしれない。

その結果としては、自前のAVX2命令を使いたい場合には、コンパイラにもAVX2命令を許可しなければならず、そうなると、出来上がった実行ファイルは、AVX2命令が動作しないPCではクラッシュする事になる。

と、いう事で、実際問題として、コンパイラにAVX2命令を許可しないとAVX2版は現行版よりも遅くなってしまうので、AVX2版は別バイナリとして提供する必要がある感じになってしまっている。

しかし、コンパイラにAVX2命令を使わせた場合、自前のAVX2コードを使わない場合にも、それなりに高速化されている訳だ。

具体的には、AVX2命令を使える、という事は、256Bitのレジスタを何本も使える格好になるので、コンパイラ的には、その分、本来ならメモリに蓄えなければならなかったデータをレジスタに蓄えておける格好になる訳だ。

なので、コンパイラにAVX2命令の利用を許可すると、処理によっては、メモリアクセスが行われなくなったり、1回のアクセスサイズが大きくなる分、アクセス回数が減ったりする訳だ。

その結果として、現在手を入れているMRSolverでは、コンパイラにAVX2命令を使わせる格好にしたお蔭で、予想以上の高速化が行われている訳なのだが、今回の高速化作業では、並列演算の方式にも手を入れている。

つまり、現行版では、8スレッド動作時に性能向上率が低かったのだが、今回、この性能向上率を上げる対策も行っているので、手持ちのMRSolverはより高速化されている訳だ。

と、いう事で、今日も長くなったので、より詳細な内容は、また、明日書く事にする。

ちなみに、まだ改良作業が終わっていないのは、未だに、FFO60-79の性能がEdax4.4のAVX2版に届いていないからなのだが、FFO40-59については、Edax4.4のAVX2版が193秒であるのに対し、改良版のMRSolverでは、パラメータ調整次第では、最高183秒という数字も出てきている。

なので、作者的には、FFO40-59については、どうとでも出来る状況なのだが、FFO60-79については、やはり、前回と同様に、最後の3項目が問題となっている。

- 2018/04/13追記 -

昨日、このブログでもチョクチョク取り上げさせてもらっている、Booby Reversi / Edax + Unified Book 2010 の作者である所のOkuhara氏からメールを貰った。

で、そのメールでは、本文にある自前AVX2命令を使った状況でコンパイラのAVX2スイッチをOffのままにしていると処理速度が大幅に遅くなる、という問題の原因について、以下の記事のURLを添えてアドバイスしてくれていた。

AVX-SSE切り替えペナルティを回避する

で、上記の記事を読んだ作者的には、Visual Studio Community 2017のAVX2スイッチをOnにした場合とOffにした場合でSSE2用のイントリンシック命令がどのようなコードに落とされるかを確認してみた。

その結果、AVX2スイッチをOnにした場合には、上記の記事にあるようなペナルティを回避するコードが出力され、Offのままにしておいた場合には、回避されない従来通りのSSE2用のコードが出力されるのを確認した。

と、いう事なので、多分、自前のAVX2命令を動作させ、かつ、コンパイラのAVX2スイッチをOffのままにしておくと、前述の記事にある様なペナルティが発生して処理速度が遅くなるモノと思われる。

上記の記事によると、手作業でペナルティを回避する方法も無い事は無い様なのだが、とてつもなく面倒そうなので、作者的には、自前のAVX2命令を使う場合には、コンパイラのAVX2スイッチもOnにする事にする。

その結果としては、まだまだAVX2命令が動作しない環境も多い事を鑑みれば、AVX2版と通常版の両方のバイナリを作成して配布する必要が生じるのだが、AVX2版については、プレミアム扱いとし、レジストキーを購入してくれた人だけが、作者サイトからダウンロードして使える様にする、というのも、一つの手ではあるかもしれない。

« AVX2命令ではシフトが便利 | トップページ | 並列演算処理の微調整 »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/66598746

この記事へのトラックバック一覧です: コンパイラのAVX2生成:

« AVX2命令ではシフトが便利 | トップページ | 並列演算処理の微調整 »

2018年11月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google