Lapack: LAPACKのプロセッサー要件

アンダーフロー自体は本当の問題ではありません。 アンダーフローの後、アルゴリズムはアンダーフローの傾向が少ないCABS1に切り替わります。 発生する問題は、TEMPが完全に単一ではなく、Zの丸めにつながることです。

考えられる解決策は、CABS1を使用して事前スケーリングしてから、ABSを使用して修正することです（最初のスケーリングのため、ABSはオーバーフローしなくなります）。 （マシンにアンダーフローが発生しないため、テストできません）

IF (RTEMP .EQ. RZERO) THEN
    RTEMP = CABS1(TEMP)
    H( I, I-1 ) = RTEMP
    TEMP = TEMP / RTEMP
    RTEMP = ABS( TEMP)
    H( I, I-1 ) = H( I, I-1 )*RTEMP
    TEMP = TEMP / RTEMP
END IF

テストは、人気のあるFORTRANコンパイラーのセットで成功するように設計されていると思います。これは、テストが実行される方法だからです。 アンダーフロー/オーバーフローの予測は非常に困難です。 少なくとも私の場合、これらのサブルーチンは、（一般的なコンパイラを使用して）徹底的にテストし、見つかったオーバーフロー/アンダーフローを修正するだけで設計されています。

ありがとうございました！ これは非常に役立ちます。
CABS1を使用してアンダーフローからの回復を試みました。 しかし、私たちの試みは十分に進んでいませんでした。 あなたの提案ははるかにうまくいくようです。 使用...

*
*        Ensure that H(I,I-1) is real.
*
         TEMP = H( I, I-1 )
         IF( DIMAG( TEMP ).NE.RZERO ) THEN
            RTEMP = ABS( TEMP)
            IF (RTEMP .EQ. RZERO) THEN 
                RTEMP = CABS1(TEMP)
                H( I, I-1 ) = RTEMP
                TEMP = TEMP / RTEMP
                RTEMP = ABS( TEMP)
                H( I, I-1 ) = H( I, I-1 )*RTEMP
            ELSE 
                H( I, I-1 ) = RTEMP
            END IF
            TEMP = TEMP / RTEMP
            IF( I2.GT.I )
     $         CALL ZSCAL( I2-I, DCONJG( TEMP ), H( I, I+1 ), LDH )
            CALL ZSCAL( I-I1, TEMP, H( I1, I ), 1 )
            IF( WANTZ ) THEN
               CALL ZSCAL( NZ, TEMP, Z( ILOZ, I ), 1 )
            END IF
         END IF
*
  130 CONTINUE

...この反復は正常に完了します（ABS（）にSSEレジスタを使用している場合でも）。

テストは、人気のあるFORTRANコンパイラーのセットで成功するように設計されていると思います。これは、テストが実行される方法だからです。 アンダーフロー/オーバーフローの予測は非常に困難です。 少なくとも私の場合、これらのサブルーチンは、（一般的なコンパイラを使用して）徹底的にテストし、見つかったオーバーフロー/アンダーフローを修正するだけで設計されています。

テストスイートは非常に役立ちます！ 私の大まかな見積もりでは、テストの1％未満が、このまたは同様のオーバーフローの問題の影響を受けています（コンパイラーを使用している場合）。 アンダーフロー/オーバーフローに対してテストをさらに堅牢にすることで、LAPACKをより多くのプラットフォームに導入できる可能性があります。 上記の（失敗した）試みはほんの一例であり、私たちの側で修正を思い付くことがほとんどできないことを明確に示しています。 複数の関連する問題を開く前に、そのような旅に興味があるかどうか、そして何が良いアプローチになるかについて、議論を始めたいと思います。

@hokbと@thijssteelの改善に

プロジェクトでの私の限られた経験を考えると、私はあなたの努力とあなたのPRをポットのガイドラインとして取る機会をいただければ幸いです。 私たちからの将来のPR ...（それでよろしければ？）

こんにちは@hokb 、

仕様を探しましたが、まだ見つかりませんでした。 任意のリンクもいただければ幸いです。 前もって感謝します！

どこにも何も指定されているかわかりません。

私たちのコンパイラは.NETCLRを対象としています。 そのJITは、ABS（TEMP）にSSEレジスタを使用することを決定します。これにより、マグニチュードの中間計算でアンダーフローが発生します。 Ifort（別の例として）は、この状況で浮動小数点レジスタを使用するため、アンダーフローしません（長さが80ビットであるため）。 実行時にコンパイラ/プロセッサに必要な精度/数値範囲に関して、LAPACKに何が期待できるかを明確に把握しようとしています。

太字のステートメント：すべての計算がIEEE 64ビット演算を使用して行われる場合、LAPACKは機能するはずです。

LAPACKは、80ビットレジスタがいつでもその計算に役立つことを期待していません。 アルゴリズムは、64ビット演算を念頭に置いて設計されています。 さて、 @ thijssteelが述べた

私たちは、これらの問題を解決するための旅の中で体系的なことは何もしていません。 一般に、アルゴリズムがテストスイートに合格すれば十分満足できます。また、80ビットレジスタからの助けがあれば、それで十分です。

倍精度のすべてのテストは、少なくとも64ビットレジスタを必要とするように設計されていますか？ それとも、今日利用可能な人気のあるFORTRANコンパイラーのセットで成功するように設計されていますか？ （上記の最初のケース（および同様の他のケース）では注意が必要な場合があります。問題を提起する必要がありますか？）

私の大まかな見積もりでは、テストの1％未満が、このまたは同様のオーバーフローの問題の影響を受けています（コンパイラーを使用している場合）。

ああ、私の。 1％？ それは恐ろしい数です。

テストはアンダーフローとオーバーフロー領域の周りで多くのテストを行っているため、ユーザーのコードよりもこの問題をトリガーするという点でテストの可能性がはるかに高いと予想されますが、それでもなおです。

アンダーフロー/オーバーフローに対してテストをさらに堅牢にすることで、LAPACKをより多くのプラットフォームに導入できる可能性があります。

より多くのプラットフォームへの移植性は確かに1つの関心事です。 もう1つの関心は、GMPなどのパッケージによる拡張精度です。私が理解しているように、精度は計算全体で固定されています。 （たとえば、あなたは256ビットの考えであり、300ビットのレジスタがありません。）

上記の（失敗した）試みはほんの一例であり、私たちの側で修正を思い付くことがほとんどできないことを明確に示しています。 複数の関連する問題を開く前に、そのような旅に興味があるかどうか、そして何が良いアプローチになるかについて、議論を始めたいと思います。

はい。 興味があります。 しかし、私たちにできることはそれだけです。 そして、私たちは私たちの皿にたくさんあります。 したがって、この問題を一度に1つずつ取り上げて、どこまで進んでいるかを確認することもできます。

いずれにせよ、GitHubに問題を投稿することは常に良い考えです。 それは問題への認識を与え、問題を解決するための助けやアイデアを集めるのに役立ちます。

私たちはこの道を進んでうれしいですが、私はそれを楽にすることをお勧めします。

たぶん、gfortranの場合、テスト目的でフラグ-mfpmath=sse -msse2を使用してコンパイルする必要があります。 これにより、すべての計算が64ビット演算で実行されるようになると思います。 でもわかりません。

プロジェクトでの私の限られた経験を考えると、私はあなたの努力とあなたのPRをポットのガイドラインとして取る機会をいただければ幸いです。 私たちからの将来のPR ...（それでよろしければ？）

もちろん！ ＃577をご覧ください。

@weslleyspereira素晴らしい！ これがCLAHQRにも同じように当てはまるかどうか、私はまだチェックしています。 私の結果をできるだけ早く投稿します（明日）

こんにちは@langou ！

太字のステートメント：すべての計算がIEEE 64ビット演算を使用して行われる場合、LAPACKは機能するはずです。

良い！ 「仕事」とは、「特定の範囲のデータが供給された場合」、特定のレジスタサイズが原因でオーバーフローしないことを意味すると思いますか？

LAPACKは、80ビットレジスタがいつでもその計算に役立つことを期待していません。 アルゴリズムは、64ビット演算を念頭に置いて設計されています。 さて、 @ thijssteelが述べた

私たちは、これらの問題を解決するための旅の中で体系的なことは何もしていません。 一般に、アルゴリズムがテストスイートに合格すれば十分満足できます。また、80ビットレジスタからの助けがあれば、それで十分です。

とてもリーズナブルですね！

私の大まかな見積もりでは、テストの1％未満が、このまたは同様のオーバーフローの問題の影響を受けています（コンパイラーを使用している場合）。

ああ、私の。 1％？ それは恐ろしい数です。

まあ、おそらくそれはそれよりも「はるかに少ない」です;）

より多くのプラットフォームへの移植性は確かに1つの関心事です。 もう1つの関心は、GMPなどのパッケージによる拡張精度です。私が理解しているように、精度は計算全体で固定されています。 （たとえば、あなたは256ビットの考えであり、300ビットのレジスタがありません。）

面白そうに聞こえますが、このような固定精度の試みの経験が不足しているため、これについてコメントすることはできません。

はい。 興味があります。 しかし、私たちにできることはそれだけです。 そして、私たちは私たちの皿にたくさんあります。 したがって、この問題を一度に1つずつ取り上げて、どこまで進んでいるかを確認することもできます。

私はまだ良い一般的なアプローチが何であるかわからない。 私の理解があまりにも素朴であるならば、私と一緒に裸でください。 しかし、オーバーフロー/アンダーフローは常に入力データとアルゴリズムの両方に依存しているのではありませんか？ したがって、コードをテストする新しい条件とそれらから回復するための新しいコードで溢れさせる代わりに、入力データの「許容範囲」を減らすことができますか？ ただし、どちらのアプローチに必要な作業についても、必要な洞察はありません。 だから私は何がもっと実現可能か判断できません。

いずれにせよ、GitHubに問題を投稿することは常に良い考えです。 それは問題への認識を与え、問題を解決するための助けやアイデアを集めるのに役立ちます。

良い。 進行中に問題を提出します。 アンダーフローを再現できずに修正を行うのは難しいことだと理解しています。 では、問題をより明確にするためにどのような情報を提供できますか？ コンクリートのアンダーフローまでの経路は役に立ちますか？ つまり、反復回数、ローカルの現在の値をファイル名などとともに提供しますか？

私たちはこの道を進んでうれしいですが、私はそれを楽にすることをお勧めします。

ここでも同じです！ :)

＃577の結果の1つは、LAPACKがFORTRANコンパイラーに依存して、適度に堅牢な（アンダー/オーバーフロー）複素数除算とABS（）を実装することです。 ドキュメントの保守を開始し、そのような要件や同様の要件を収集する必要があるのでしょうか。 これらは、LAPACKを他の/新しいコンパイラで使用したい人、コンパイラビルダー、およびLAPACKアルゴリズムの一部またはすべてを他の言語に転送したい人にとっても同様に重要で便利です。

もちろん！ この情報を十分に文書化しておくとよいでしょう。

まず、フォームのファイルLAPACK/SRC/z*.f （COMPLEX * 16アルゴリズム）内のすべての分割を（多分）追跡することに時間を費やしました。

 REAL / COMPLEX   or   COMPLEX / COMPLEX

合計53個のファイルが見つかりました。 添付ファイルを参照してください： complexDivisionFound.code-search

• そのために、Visual StudioCodeでREGEX式を使用しました。

  \ n。* / ^ 0-9 （？！DBLE）（?! REAL）（?! MIN）（?! MAX）[^ 0-9]

たぶん、gfortranの場合、テスト目的でフラグ-mfpmath=sse -msse2を使用してコンパイルする必要があります。 これにより、すべての計算が64ビット演算で実行されるようになると思います。 でもわかりません。

はい、GCCを使用する場合は必要ですが、このフラグはx86-64でもデフォルトで設定されている必要があります。 以下のドキュメントの抜粋はGCC11用ですが、はるかに古いバージョンのGCCでも同じ動作を示すはずです。 GNUコンパイラコレクション（GCC）の使用：3.19.59x86オプション

sse

SSE命令セットに存在するスカラー浮動小数点命令を使用します。 この命令セットは、Pentium III以降のチップでサポートされており、AMDラインではAthlon-4、Athlon XP、およびAthlonMPチップでサポートされています。 以前のバージョンのSSE命令セットは単精度演算のみをサポートしているため、倍精度および拡張精度の演算は引き続き387を使用して実行されます。Pentium4およびAMD x86-64チップにのみ存在する後のバージョンは、倍精度演算をサポートします。それも。

x86-32コンパイラの場合、SSE拡張を有効にしてこのオプションを有効にするには、 -march=cpu-type 、 -msseまたは-msse2スイッチを使用する必要があります。 x86-64コンパイラの場合、これらの拡張機能はデフォルトで有効になっています。

結果として得られるコードは、ほとんどの場合かなり高速であり、387コードの数値的不安定性の問題を回避するはずですが、一時的なものが80ビットであると予想する既存のコードを壊す可能性があります。

これは、x86-64コンパイラであるDarwin x86-32ターゲットのデフォルトの選択であり、 -ffast-mathが有効になっている場合のSSE2命令セットを使用したx86-32ターゲットのデフォルトの選択です。

例：
XEIGTSTZ <zec.in-ZLAHQRのアンダーフローが原因で失敗します。
再現手順：ZGET37-> knt == 31、ZHSEQR-> ZLAHQR-> 2番目のQRステップ（ITS == 2）の最後に、次のコードがアンダーフローを引き起こします（特定のレジスタでは、以下を参照）

TEMP = H( I, I-1 )
    IF( DIMAG( TEMP ).NE.RZERO ) THEN
        RTEMP = ABS( TEMP)    ! <-- underflow on TEMP = (~1e-0173, ~1e-0173)
        IF (RTEMP .EQ. RZERO) RTEMP = CABS1(TEMP)
        H( I, I-1 ) = RTEMP
        TEMP = TEMP / RTEMP
        IF( I2.GT.I )

私たちのコンパイラは.NETCLRを対象としています。 そのJITは、ABS（TEMP）にSSEレジスタを使用することを決定します。これにより、マグニチュードの中間計算でアンダーフローが発生します。 Ifort（別の例として）は、この状況で浮動小数点レジスタを使用するため、アンダーフローしません（長さが80ビットであるため）。 実行時にコンパイラ/プロセッサに必要な精度/数値範囲に関して、LAPACKに何が期待できるかを明確に把握しようとしています。

要点をまとめると：

• 50万行のFortran77をC＃にトランスパイルしました。
• .NETジャストインタイムコンパイラを使用すると、トランスパイルされたコードのテストが失敗します。
• インテルFortranコンパイラー（ifo​​rt）を使用すると、バニラLAPACKコードのテストは成功します。
• 2つのケースで観察された違いは、アンダーフローを回避するifortによる80ビット中間体の使用です。

正しい？

デフォルトでは、GCCはx86-64上の64ビット浮動小数点レジスターのコードのみを生成します。私のマシンでは通常、1つまたは2つを除いてすべてのLAPACKテストに合格します。

Netlib LAPACKテストスイートはGCCでコンパイルするときに合格しますか？

編集：解決済みhttps://github.com/Reference-LAPACK/lapack/pull/577#issuecomment -859496175

たぶん、gfortranの場合、テスト目的でフラグ-mfpmath = sse-msse2を使用してコンパイルする必要があります。 これにより、すべての計算が64ビット演算で実行されるようになると思います。 でもわかりません。

MacOSとLinuxの両方でGCC11を使用して-mfpmath=sse -msse2を試しました： https ： https ：

@ hokb 、SSEフラグを使用してGCCでhttps://github.com/Reference-LAPACK/lapack/issues/575#issuecomment -855880000で言及したオーバーフローの問題を再現できますか？ それを手伝ってくれませんか。

@weslleyspereira私はGCCを試したことがありません。 私がアクセスできる/実行中のセットアップは、Windowsでのifortだけです。 テストのためにcygwin経由でGCCを起動して実行するには、数日かかります（特に、現在のホリデーホテルの部屋から...：|）ただし、このチャレンジに挑戦する必要がある場合はお知らせください。
少なくとも、 https： //godbolt.org/z/YYv5oPxe9によると、フラグを使用しても、gfortranによって生成されるコードには影響しません。 しかしもちろん、テスト実行だけが確実にわかります...

私はウィンドウを使用していませんが、ここにあります。 まず、Ubuntuでifortを使用してLAPACKをテストし、何が起こるかを確認します。 休日をお楽しみください！