問題タブ [fma]

-ffp-contractGNU GCC のフラグについて質問があります ( https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.htmlを参照)。

フラグのドキュメントは次のように書かれています。

-ffp-contract=off浮動小数点式の縮小を無効にします。-ffp-contract=fastターゲットがそれらをネイティブにサポートしている場合、融合乗加算演算の形成などの浮動小数点式の縮約を有効にします。-ffp-contract=on言語標準で許可されている場合、浮動小数点式の短縮を有効にします。これは現在実装されておらず、 と同等に扱われ-ffp-contract=offます。デフォルトは です-ffp-contract=fast。

今質問：

• fast と on はどう違いますか？
• FMA 以外に収縮の例はありますか (または、fusion-mult サブのようなもの)?

cuda で fma(a, b, c) を使用すると、式 a b+c が単一の三項演算で計算されることを意味します。しかし、-a b+c を計算したい場合、fma(-a, b, c) を呼び出すには、もう 1 つの乗算操作が必要ですか?

IPOPT で最適化する C++ 関数がいくつかあります。コスト関数、制約関数などは C++ で記述されていますが、コードはもともと C インターフェイスを使用するように記述されています。それが問題であることが判明しない限り、私はまだそれを変更することを気にしていません.

とにかく...ベクトル化フラグを使用して/使用せずにプログラムをコンパイルすると、オプティマイザーが異なる方法で収束するという予期しない動作が観察されています。具体的には、CMakeLists ファイルには、

これらの設定でオプティマイザーを実行すると、オプティマイザーは約 100 回の反復で収束します。ここまでは順調ですね。

ただし、ARM (特に Android) 用にコンパイルした場合、パフォーマンスが Intel プロセッサとは大幅に異なるため、ベクトル化は発生しないと考える理由があります。Eigen のドキュメントには、64 ビット ARM では NEON 命令を常に有効にする必要があると記載されていますが、それが行われていないのではないかと疑う理由があります。とにかく、それはここでの問題ではありません。

この疑いがあるため、ベクトル化を無効にした場合に Intel プロセッサのパフォーマンスがどの程度低下するかを確認したいと考えました。これにより、ベクトル化がどの程度行われているか、また ARM でどの程度の改善が期待できるかがわかります。ただし、コンパイラフラグを次のように変更すると、

(または、単に AVX (fma なし) を使用する場合)、オプティマイザーから同じ一般的なソリューションが得られますが、収束パフォーマンスは大きく異なります。具体的には、ベクトル化を行わない場合、オプティマイザーは解に収束するまでに約 500 回の反復を行います。

要約すると：

ソースコードではなく、文字通りcmakeファイルの1行だけを変更しています。

なぜこれが発生するのかについて、いくつかの提案をお願いします。

私の考えとその他の背景情報：

ベクトル化を使用するバージョンと使用しないバージョンのどちらでも何らかの丸め処理を行う必要があり、それによって IPOPT の収束が異なるように思われます。AVX フラグと FMA フラグを追加しても、関数の出力は変わらず、計算にかかる時間だけが変わるという印象を受けました。私は間違っているようです。

私たちが観察している現象は、オプティマイザーが常に同じ解に収束することを観察しているため、私には特に奇妙に思えます。これはどういうわけか、問題があまりにも悪条件であってはならないことを示唆しています。しかし一方で、ベクトル化フラグの有無でオプティマイザーの動作が異なるという事実は、ベクトル化された命令によって生成される小さな残差が何であれ、問題が実際に敏感であることを示唆しています。

心に留めておくべきもう 1 つのことは、IPOPT をライブラリにプリコンパイルし、そのプリコンパイル済みライブラリに対してコードを単にリンクしていることです。したがって、AVX フラグと FMA フラグがオプティマイザー自体に影響を与える可能性はないと思います。これは、ベクトル化が有効かどうかに応じて、関数が明確に異なる値を出力する必要があることを意味しているようです。

興味のある方は、ここに完全な cmake ファイルがあります