Pytorch: RFC：決定論的アルゴリズムを強制するためにtorch.deterministicフラグを追加します

これは私からの親指です。 問題は主に、これをコードベースのどこにでも実際に展開する方法です。 私たちが決定論的であると主張することはさらに悪いことではありませんが、密かにそうではありません:)

私はそれですべてです。私のアプローチは、決定論がオンになっているときに操作とエラーにフラグを立てることですが、そうではないことがわかっています。

非決定論的な操作でのエラーは厳しすぎると思います。 警告はよりスムーズな体験のようです

デフォルトはthrowである必要があると思いますが、そこで複数値のプロパティをサポートできると思います（非決定論的は問題ありません、警告、throw）。

警告のユースケースは実際には見られないことを認めなければなりません。 人々がそれをオンにするのに十分な決定論を気にするとき、彼らはおそらくエラーを予期するでしょう。 特定の呼び出しではいつでもオフに切り替えて、そこにある非決定性に問題がないことを伝えることができます。

エラー、警告、適切なドキュメント...
後者は必須です。
警告またはエラー？ エラーが発生します。

投げるのは素晴らしいようです。 私は、投げる代わりに警告するオプションを与えることは合理的であるように思われるというアダムに同意します。

量り入れてくれてありがとう。結局、三元旗の主な努力は旗そのものであり、それは難しいことではありません。
Context.hにフラグを追加し、（ユーティリティ関数を介して）AT_ERRORとAT_CHECKを振りかけます。

こんにちは、
この旗のニュースはありますか？
決定論は非常に重要です。
私の経験から、現在のバージョンでは、固定シードを使用して、1 gpuで、精度1e-16までの決定論が可能です。 微小な違いが増幅され、結果が発散する可能性があることに注意してください。

multigpuの場合も考慮してください（少なくとも固定のK gpusの場合、動作は決定論的である必要があります。理由により、時々故障するある種の決定論を達成することができます。今のところ理解していません（ナイトリービルド1.2.0.dev20190616を使用）。 私は今（それに苦しんでいます1 、 2 ）。

ありがとう！

@ t-viあなたはこれに積極的に取り組んでいますか？

私はあなたがそれをするのを妨げたくありません。

@ t-vi不明な点がある場合は申し訳ありませんが、これに取り組む予定はありません:)。 誰かが積極的にそうしているのかどうかを理解しようとしていただけです。

ほぼ1年経っても、非決定論的補間の問題はまだ解決されていません。

コミュニティがこの機能を追加することを願っています:)

たぶん、決定論的な補間はユーザーに大きな助けをもたらすでしょう。

〜私はまだ実際に宣伝していませんが、割り当てられた開発者リソースよりもユーザーの関心が高いように思われるため、これを設定したときにgithubスポンサーシップページに投票できるプロジェクトとしてリストされています。
年末までに順調に進展できると確信しており、補間は確かに修正方法の計画の1つです（問題のどこかにあるfoldの擬似コードと同様）が、そうではありません。私自身の優先順位リストの上位にはありません。〜
面白くないことがわかった。

決定論的補間は大きな助けになります。 リンク

ユーザーフィードバックに基づくバンピング優先度、特にCUDAの場合

修正されてよかったです、ありがとうございます！

@ t-vi公平を期すために、「バンピング優先度」は「修正中」と同等ではないと思います:)。

解決策を楽しみにしています！

colesburyは、決定論的アルゴリズムの1つのキラーな理由は、決定論が実際に問題であるためではなく、これをオンにすると除外できると述べました;）

torch.experimental.deterministicはRNGシードとどのように相互作用する必要がありますか？ 手動シードが設定されていない場合、デフォルトシードを設定する必要がありますか？ 手動シードが設定されていない場合、警告を発行する必要がありますか？

ユーザーがシードを設定していない場合は、シードを設定しないことをお勧めします。 1つは、不要な2つのインターフェイスを結合しているためです（決定論を気にするユーザーは、RNGを非常によく理解していると思います）。 さらに重要なことに、これを確実に行うのは非常に困難です。 マルチプロセス/スレッド化されたアプリケーションでRNGを使用したり、他のtorch.Generatorサブクラスを使用したり、 numpy.randomたりすることもできます。

警告については、設定するのに適切な場所がある場合にのみわかりません（たとえば、RNGが使用されているのと同じモジュール/関数ではなく、 determinism=True前にシードを強制しますか？）。

torch.backends.cudnn.deterministic=Trueを設定しても、補間演算子が決定論的ではないことに興味があります。 pytorch補間はcudnnを使用しませんか？

そうではないかもしれません。 補間の実行をnvprofして、確実にチェックすることができます。

torch.experimental.deterministicが実装されたら、関数呼び出しでdeterministic引数を提供し続ける必要があるかどうか疑問に思っています。 ユーザーは、一部の操作には決定論を、他の操作には速度を好む可能性があるため、おそらくそうすべきです。

引数を保持すると、 torch.experimental.deterministicと関数のdeterministicフラグが互いに反対になるとどうなりますか。 torch.experimental.deterministic = Trueは「すべての場合に決定論を使用する」を意味するか、「デフォルト値として決定論を使用する」を意味する必要がありますが、関数呼び出しでdeterministic引数が指定されている場合は、その特定の関数呼び出しの設定。」 言い換えれば、以下のコードはどのように処理する必要がありますか？ torch.backends.cudnn.deterministicフラグが同様の状況でどのように機能するかを誰かが知っていますか？

torch.experimental.deterministic = True
torch.some_operation(deterministic=False)

@kurtamohler良い質問です。 最も簡単な解決策は、 bool? deterministic=Noneにしてから、 Noneを「 torch.experimental.deterministic尊重する」という意味に解釈することです。それ以外の場合は、ユーザーが要求したものを正確に使用します。

私たちは、一種の畳み込みと似たような状況を持っているが、それは行われていた方法があることがありましたconvolutionなしでbenchmark 、引数、および_convolution明示して基準。

これらの解決策のどちらも受け入れられると思います。 ただし、畳み込みアプローチには、内部deterministicフラグをユーザーに表示されるAPIにリークしないという追加の利点があります（内部APIを使用しない場合）。

「どこでも決定論的でありたいが、_この特定の演算子ではない_」の理由は何ですか？ これは、多くの演算子（およびほとんどの複雑な演算子）に追加の入力を追加することを保証するのに十分な一般的なユースケースであると本当に考えられていますか？ IMOは、決定論を切り替えるためのコンテキストマネージャーを提供する方がよいでしょう。

@apaszke 、ええ、決定論を切り替えるためにコンテキストマネージャーを使用する方が良いと思います。 deterministic引数を演算子に追加する必要があるとは言いませんが、一部の演算子にはすでに引数があります。 それらをすべて削除してBCを壊すのが最善でしょうか、それともそれらを維持してtorch.experimental.deterministicをオーバーライドできるようにするのが最善でしょうか？

削除するか、少なくともプライベートにする必要があります（つまり、アンダースコアプレフィックスまたはsth）。

補間関数の決定論的機能が閉じられ、実装されないのではないかと思いますか？

いいえ、PyTorchのすべての関数の決定論的バージョンを受け入れます

@ezyangどのpytorchバージョンが決定論的なF.interpolate関数を持っていますか？ pytorch 1.6から始まっていますか？ または、最新の安定バージョン（1.5）で利用できますか？ または、ソースからPytorchをダウンロードしてインストールする必要がありますか？

私はこれに取り組み始めてうれしいです

上記のコミットはフラグを追加するだけで、まだ操作には影響しません。 誰かがそれを見て、私が何か間違ったことをしたかどうか、またはこれまでに何かを改善できるかどうかを教えていただければ幸いです。 これは、 torch.backends.cudnn.deterministic実装方法に基づいています。

これは問題ないように見えますが、内部の名前には実験的なものを含めるべきではないように感じます（表面上は、実験的なものにしたくないので、すべての実装ビットの名前を変更する必要はありません！）

@ezyang 、ええ、それは理にかなっています、名前を変更します。

@ t-viがこの問題に関する以前の作業で行ったのと同様に、 torch.experimental.deterministic_error_levelを追加しました。 deterministic_error_levelは、 deterministic == Trueと特定の関数に決定論的な実装がない場合に、エラー/警告の動作を制御します。 2（エラー）、1（警告）、または0（サイレント）に設定できます。

ユーザーがそれを他の値に設定した場合、キャッチ可能なpythonランタイム例外をスローしたいと思います。 通常、この種の動作にはTORCH_CHECK()を使用しますが、この場合、例外をキャッチできず、理由がわかりません。 これがTORCH_CHECK()呼び出しです：リンク

これは、そのチェックが失敗したときに起こることです。

>>> import torch
>>> try:
...     torch.experimental.deterministic_error_level=50
... except:
...     print('exception caught')
... 
terminate called after throwing an instance of 'c10::Error'
  what():  error level 50 is invalid, must be one of 0: None, 1: Warn, or 2: Error
Exception raised from longToErrorLevel at ../aten/src/ATen/Context.cpp:85 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 0x58 (0x7f53e2cc0878 in /work/kurtamohler/development/pytorch-deterministic-flag/torch/lib/libc10.so)
frame #1: at::Context::longToErrorLevel(long) + 0x122 (0x7f53f6d61a82 in /work/kurtamohler/development/pytorch-deterministic-flag/torch/lib/libtorch_cpu.so)
frame #2: THPModule_setDeterministicErrorLevel(_object*, _object*) + 0x31 (0x7f53fb5625d1 in /work/kurtamohler/development/pytorch-deterministic-flag/torch/lib/libtorch_python.so)
<omitting python frames>
frame #23: __libc_start_main + 0xe7 (0x7f5432d62b97 in /lib/x86_64-linux-gnu/libc.so.6)

Aborted (core dumped)

私がそれを修正する方法を誰かが知っているなら、私に知らせてください。

@kurtamohlerはTHPModule_setDeterministicErrorLevel HANDLE_TH_ERRORS / END_ HANDLE_TH_ERRORSマクロがありませんか？ これらは、C ++例外をキャッチし、それをPythonエラーリターンに変換するために必要です。

ああ、それでした、@ colesburyに感謝します！

atomicAddすべての呼び出し元に非決定論的アラートを追加し始めています。 一部の発信者atomicAdd 、特定の場合にのみadaptive_avg_pool3d_backwardは、 (isizeW%osizeW != 0) || (isizeH%osizeH != 0) || (isizeT%osizeT != 0)がtrueの場合にのみ使用されます。 これらの場合にのみアラートを出し、エラーメッセージでそれらを伝えようとする必要がありますか、それともatomicAddが使用されるかどうかにかかわらず、これらの関数が呼び出されるたびにアラートを出すだけで大丈夫ですか？

無条件にアラートを送信すると、実装が簡単になり、理解しやすくなります。

@ngimel 、私はCUBLAS_WORKSPACE_CONFIGを使用して決定論的なストリームの使用を確実にする方法を考えてきましたが、考慮すべき2つの主要なアプローチがあると思います。

影響を受けるCUDAバージョン（現時点では10.2以降）のいずれかを使用していて、 torch.set_deterministic(True)が呼び出された場合は、 std::getenvを使用して、 CUBLAS_WORKSPACE_CONFIGが:16:8いずれかであることを確認します。 :4096:8 。 そうでない場合は、（1）または（2）のいずれかを実行します。

1. 変数を適切に設定するようにユーザーに指示するエラーをスローします。

2. 変数をputenv （Windowsでは_putenv ）で自動的に設定します。 ただし、これに関連するいくつかのさらなる設計上の決定があります。 :16:8 （パフォーマンスは低くなりますがメモリ使用量は少なくなります）または:4096:8 （パフォーマンスは高くなりますがメモリ使用量は多くなります）を選択する必要がありますか？ また、ユーザーが変数を他の非決定論的値に設定した場合、元の値を追跡し、 torch.set_deterministic(False)が呼び出された場合にそれを復元する必要があります。そうしないと、ユーザーに次のように通知するエラーがスローされる可能性があります。変数またはその他のスキームの設定を解除する必要があります。

また、アプリケーションの実行中に変数を設定しても実際に影響があるかどうかわからないため、オプション（2）が可能かどうかもわかりません。 変数は、CUDAランタイムの開始時、またはcuBLASハンドルの作成時に一度だけチェックされる可能性があります。 これに関する情報が見つからなかったので、おそらく実験的に調べる必要があります（どちらの方法でもテストを作成するには、非決定論的なストリーム使用量の再現機能を使用する必要があるため、これを調べます） 。 環境変数を使用するのではなく、API呼び出しも探しましたが、CUDAはそれを提供していないようです。

どのオプションが良いかについて強い意見がありますか？ オプション（2）はおそらくユーザーフレンドリーですが、オプション（1）よりも透過性が低い可能性があります。

アプリケーションの実行中に変数を設定しても実際に影響があるかどうかはわかりません

この質問をフォローアップするために、pytorchスクリプト内で環境変数を設定しても、CUDAストリームの決定論には影響しないようです。 https://github.com/pytorch/pytorch/issues/39849のスクリプトを変更して、複数回実行し、トレーニング統計を比較して、非決定論的な動作を確認しました。 CUBLAS_WORKSPACE_CONFIG=:4096:8を設定して、決定論的なストリームの使用を保証しようとします： https ：

それを実行すると、スクリプト内で変数を設定しても決定論的な動作が得られないことがわかります。

$ python cuda_stream_nondeterminism.py 
Before setting var: not deterministic
After setting var: not deterministic
After restoring old var: not deterministic

ただし、スクリプトの外部で設定された環境変数を使用して実行すると、決定論的になります。

$ CUBLAS_WORKSPACE_CONFIG=:4096:8 python cuda_stream_nondeterminism.py 
Before setting var: possibly deterministic
After setting var: possibly deterministic
After restoring old var: possibly deterministic

トレーニング関数を5回しか実行しないため、「おそらく決定論的」と出力され、動作が実際には決定論的でなくても幸運になる可能性があることに注意してください。

たぶん、cudaストリームを再初期化できれば、変更されたCUBLAS_WORKSPACE_CONFIG変数を尊重するように強制されます。 それを試してみたいのですが、実行時にそれを実行する方法や可能性すらわかりません。 誰かが知っているなら、私に知らせてください。

次の方法で新しいストリームを作成して使用できることがわかりました。

with  torch.cuda.stream(torch.cuda.Stream()):

ただし、新しいストリームは、変更された環境変数設定を尊重しません。 torch.cuda.init()も見つかりましたが、残念ながら、cudaがすでに初期化されている場合は問題ありません。

したがって、他に試すことができない限り、ワークスペースの構成を自動的に変更することはできないように思われるため、ユーザーに設定するように指示するエラーをスローする必要があるかもしれません。

はい、cudaコンテキストが初期化された後に環境変数を設定しても効果がないため、残念ながら、それはすべてか無かの解決策です。 ユーザーに設定するように指示するエラーをスローすることは合理的に聞こえます。

現在、nvcc以外のコンパイル済みファイルからCUDAバージョンを確認することはできないようです。そのため、 aten/src/ATen/cuda/detail/CUDAHooks.hに追加する必要があると思います（cuDNNバージョンの確認はそのインターフェイスの一部です） 。 誰かがもっとよく知っているなら、私に知らせてください。

上記のコミットはエラーを追加します。 しかし、私は今、ユニットテストをどうするかを理解する必要があります。 2つの問題があります：

• エラーが正しいケースでスローされていることをテストするには（cuda> = 10.2で、 CUBLAS_WORKSPACE_CONFIGが正しく設定されていない）、テストインフラストラクチャは、テストを実行する前に環境変数を自動的に変更できる必要があります。
• 既存のtorch.set_deterministicテストが失敗しないようにするには、 CUBLAS_WORKSPACE_CONFIGを自動的に適切に設定する必要があります。 cuda> = 10.2を使用するすべてのCIジョブで、デフォルトでこの変数を設定できる可能性があります。

Pythonスクリプトから環境変数を設定してから、トーチモジュールをリロードして、新しい値を尊重することができることがわかりました。

>>> import torch
>>> torch.set_deterministic(True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/work/kurtamohler/development/pytorch-deterministic-flag-cuda-env-var/torch/__init__.py", line 306, in set_deterministic
    _C._set_deterministic(d)
RuntimeError: To enable deterministic behavior with CUDA >= 10.2, you must set environment variable CUBLAS_WORKSPACE_CONFIG=:4096:8 or CUBLAS_WORKSPACE_CONFIG=:16:8. For more information, go to https://docs.nvidia.com/cuda/cublas/index.html#cublasApi_reproducibility
>>> import os
>>> os.environ['CUBLAS_WORKSPACE_CONFIG'] = ':4096:8'
>>> from importlib import reload
>>> torch = reload(torch)
>>> torch.set_deterministic(True)

トーチをリロードすることでCUDAがこの変更を尊重するかどうかはわかりませんが、少なくともこれにより、エラーメッセージの単体テストを行うことができます。 質問する必要がありますが、ユニットテスト内でトーチモジュールをリロードすることに問題はありますか？

編集：変更された環境変数を表示するためにトーチをリロードする必要がないことがわかりました。 また、変数を変更した後にリロードしても、CUDAランタイムには影響しません。

上記のコミットは、以前のコメントで述べたすべての懸念に対処します。 torch.set_deterministic()を呼び出すAPIテストをラップするデコレータを追加し、必要な場合にのみCUBLAS_WORKSPACE_CONFIG=:4096:8一時的に設定しました。 また、決定論的フラグとCUBLAS_WORKSPACE_CONFIG設定を、テストが実行される前の状態に復元します。

再現性のドキュメントには、決定論的なCuDNNの動作には次のものが必要であると記載されていることに気付きました。

torch.backends.cudnn.deterministic = True
torch.backends.cudnn.benchmark = False

このスレッドの誰かがbenchmarkが正確に何であるかを知っていますか、そしてなぜtorch.backends.cudnn.deterministic = Trueだけでは不十分ですか？

torch.is_deterministic() == True場合、 benchmarkを強制的にオフにすることができます。 つまり、 ctx.benchmarkCuDNN()をat::_convolution()に直接渡すのではなく、次の行でctx.benchmarkCuDNN() && !ctx.deterministic()にする必要があります： //github.com/pytorch/pytorch/blob/ master / aten / src / ATen / native / Convolution.cpp＃L602

この変更を行わない場合、 set_deterministicとCuDNNを使用する人々はこれを行う必要があるようです。

torch.set_deterministic(True)
torch.backends.cudnn.benchmark = False

set_deterministic()だけではすべてをカバーできないという意味で、私の意見では混乱を招きます。

cc @ezyang @colesbury @ t-vi @ngimel

新しい畳み込み構成に遭遇すると、 benchmark=Trueは利用可能なすべてのcudnn実装を実行し、選択した実装をキャッシュして最速の実装を選択するため、同じパラメーターを使用した後続のすべての畳み込み呼び出しでそれが使用されます。 したがって、 deterministicもTrueに設定されている場合、このキャッシュが存続する限り、つまり同じプロセスにいる限り、結果は決定論的です。 実行時間が近い実装がある場合、次にプロセスを開始してベンチマークを再度実行すると、別の実装が勝つ可能性があり、結果は（上記の意味ではまだ決定論的ですが）前の実行とは異なります。 したがって、実行間の決定論を保証するには、ベンチマークをオフにする必要があります。

そうですか。 したがって、一部のアプリケーションでは、おそらくプロセス内の決定論のみが重要であり、プロセス間の決定論は重要ではないため、 torch.set_deterministic(True)を設定した場合でも、ベンチマークを使用できると便利です。 その場合、現在の動作を変更するべきではありません。 それを明確にするためにドキュメントを更新する限り、問題は発生しません。

PyTorchの寄稿者がtorch.set_deterministic()サポートを追加できるようにwikiページを作成しました： https ：

どんな改善でも大歓迎です。

また、「現在サポートされていない機能」セクションがこのwikiに含まれるべきかどうか、または新しいgithubの問題として優れているかどうかもわかりませんでした（wikiページがそれにリンクしている可能性があります）。 誰か好みがありますか？

こんにちは、 torch.deterministic今後の計画についてお話ししたいと思います。 答える必要のあるいくつかの高レベルの質問があります：

1. torch.deterministicのセマンティクスは何ですか？ ユーザーは何を期待していますか？ ベストエフォートは実際にユーザーにとって有用ですか？ それは便利ではない場合、それは定義することをお勧めしますtorch.deterministic何それが制御操作の面で？
2. torch.deterministicフラグができたので、 deterministic=キーワード引数を公開APIから完全に削除するのは理にかなっていますか（ bmm 、私はあなたを見ています）。
3. この作品の最終的なゲームは何ですか？ あなた（@kurtamohler）は、一般的なコミュニティと比較して、どれだけの作業を行う予定ですか。ここであなたの任務を終えると、合理的な状態はどのようになりますか？

（1）から始めて、torch.deterministicの現在のドキュメントには次のように書かれています。

     r"""Sets a global flag to force all operations to use a deterministic
    implementation if available. If an operation that does not have a
    deterministic implementation is called while this setting is True, the
    operation will throw a RuntimeError.

    Note that deterministic operations tend to have worse performance than
    non-deterministic operations.

これは最終的な最終状態には当てはまるかもしれませんが、これは現在の状況を不正確に表しており、多くの操作が監査されておらず、特定のモデルについて、 torch.deterministicが実際にそれを実行するかどうかはわかりません。缶に言い、モデルを決定論的にします/ nondetをヒットしたときにエラーを発生させます。 したがって、基本的に、私たちの実装はこれらのセマンティクスに関してバグがあり、予見可能な将来にわたってバグがあり続けるでしょう。 これは、良い状態ではありません。

これを改善するために、torch.deterministicのドキュメントを変更することができます。 いくつかの可能な変更：

• torch.deterministicはベストエフォートですが、非決定論を捕らえないことがわかった場合は、バグを報告してください
• torch.deterministicは、これらの演算子の動作を切り替えます（そして、切り替えた演算子の完全なリストを提供します）

2番目の箇条書きは（2）につながります。決定論を切り替える方法としてtorch.deterministicが存在する場合、ユーザーAPIで直接決定論をサポートすることはそれほど重要ではありません。 したがって、bmmにdeterministic引数を追加するべきではなかったでしょう。 何かを直接切り替えたい場合は、内部関数を公開することを検討するかもしれませんが、 deterministicを関数自体で直接使用することはできません。

どう思いますか？ ドキュメントを変更することは、おそらく持続可能な道を歩むための最も簡単な方法だと思います。 網羅的なリストを作成する方法など、他にもいくつかの詳細がありますが、これらのセマンティクスは、実際には真にならない「理想的な」セマンティクスよりもおそらく理にかなっています。

cc @gchanan @mruberry

@ zou3519は、 https： //github.com/pytorch/pytorch/pull/38683#issuecomment-662590937でもQと交差しました

@ ezyang 、 @ mruberryの質問をお寄せいただきありがとうございます。 私が書いた文書が現在の状態の誤った表現であることに同意します。

torch.set_deterministic()影響するすべての関数を網羅的にリストして、ユーザーに嘘をつかないようにするというアイデアが好きです。 1.6.0、@ zou3519に追加していただきありがとうございます。

deterministic設定を直接関数の引数として提供するべきではないことに同意します。

エンドゲームに関しては、必要な限りこれに取り組んでいきたいと思いますが、誰もがすぐに助け方を学べるように設定する必要があります。

長期的には、影響を受ける機能の完全なリストを提供することは有効な決定だと思いますが、戦略だけで決定論的フラグの有用性を最大化するとは思いません。 次のように（1つの特定の環境で）関数を分類できます。

1. 決定論的
2. デフォルトでは非決定論的ですが、決定論的フラグ（エラーまたは代替実装のいずれか）をサポートしています
3. 非決定論的であり、決定論的フラグをサポートしていません

もちろん、理想的なケースは、カテゴリ3を完全に削除することです。そうすれば、カテゴリ2の関数のリストで十分です。 ただし、カテゴリ3の関数はかなりの期間存在します（または、すべての貢献者が決定論の問題を認識していない場合、またはコミットによって関数の決定論が誤って削除される場合などは、永久に存在します）。 したがって、すべてのカテゴリ2関数の完全なリストがある場合でも、リストに表示されない関数が決定論的であるかどうかをユーザーが簡単に知る方法はありません（カテゴリ1または3の可能性があります）。 たとえば、 torch.addはリストに表示されないので、ユーザーはそれが決定論的であることをどのようにして知るのでしょうか。

おそらく、カテゴリ3の機能のリストを維持することも考えられます。 しかし、これらのリストを手動で維持することは多くの理由で非常に難しいので、それをいくらか自動化できるかどうか疑問に思います。 すべての関数で決定論テストを実行するCIジョブを設定できる可能性があります。 関数が決定論的であることを100％帰納的に証明することは不可能であり、運が悪ければ、非決定論的関数が同じ結果を複数回与えることがあります。 ただし、これらのテストを頻繁に実行するほど、各関数がどのカテゴリに含まれるかについて自信を持てるようになります。

また、各機能や各プラットフォームについて私たちが知っていることと知らないことをすべてユーザーに最も効率的に伝える方法についての質問もあります。 たぶん、各プラットフォームですべてのカテゴリ2と3の関数のテーブルを作成できます。 決定論テストでこのテーブルが正しいことを自動的に検証できれば便利です。

ブレーンストーミングをするだけで、これらのアイデアは価値があるよりも難しいかもしれません。 より実用的な計画は、たとえ理想的でなくても、はるかに持続可能である可能性があります。

torch.add決定論的ですか？

import torch
n = 512
device = 'cuda'
a = torch.arange(n**3, device=device, dtype=torch.float32)
a = a.reshape((n, n, n))
b = torch.arange(n**3, device=device, dtype=torch.float32)
b = b.reshape((n, n, n))
out_zero = torch.zeros((n, n, n), device=device)
out_zero = out_zero.set_(out_zero.storage(), storage_offset=0, size=a.size(), stride=(1,1,1))
out_one = torch.zeros((n, n, n), device=device)
out_one = out_one.set_(out_one.storage(), storage_offset=0, size=a.size(), stride=(1,1,1))

torch.add(a, b, out=out_zero)
torch.add(a, b, out=out_one)
(out_zero == out_one).all()
: tensor(False, device='cuda:0')

オーバーラップしたテンソルは、私たちが目指している決定論契約に違反していることを文書化する必要があります。

「決定論」フラグの影響を受ける操作をリストするのは良いことのように思えます。 ただし、少し後退すると、実際には2つのことについて話しているように見えます。

• 可能な場合は、決定論的なバージョンの操作を要求する（ use_deterministic ？）
• 操作が非決定的である場合の警告

最初のもののフラグは簡単に思えます。 ただし、2番目は少し注意が必要です。 特にバージョンやハードウェア間で、oneDNN、cuDNN、MAGMAなどの数学ライブラリの操作が決定論的であるかどうかを判断するのが難しいのではないかと心配しています。 @kurtamohler、これに対処する最善の方法についてのアイデアはありますか？ おそらく、すべてのネイティブの非決定論的操作について警告し、数学ライブラリの呼び出しが行われたときにも警告することができますか？ プロセスごとに1回の警告は、それほど煩わしいものであってはなりません。

警告へのこのアプローチでは、稼働する前に多くのアルゴリズムと呼び出しサイトを確認する必要がありますが、決定論的アルゴリズムが利用可能な場合は、フラグをブロックして選択する必要はありません。

（議論中の3番目のことは、決定論的アルゴリズム選択を（グローバルフラグを介して、または関数のkwargsとして）提示するための最良の方法ですが、フラグの計画を決定するまで、その議論を遅らせることができると思いますか？）

ここで完璧を善の敵にすべきではないと思います。 PyTorchで自己重複テンソルを使用することが100％安全であった時期はわかりませんが、一般の人々が使用するのはそうではないという印象があります。

フォーラムからの私の印象は、ほとんどの人が何かを2回実行し、それから異なるグラデーションを取得することに驚いていることです。ほとんどの場合、atomicAddを使用するPyTorchのネイティブ関数の1つが原因です。
そのための警告が表示された場合は、人々が疑問に思っているほとんどのケースをカバーしています。 その半分のように感じるものは、実際には後方へのアップスケーリングによるものです。

外部ライブラリに関する限り、これがベストエフォートであり、問​​題を知るたびに警告を追加することを明確に述べる必要があると思いますが、私の印象では、ネイティブカーネルが実際に最も重要なものであると思います。

PyTorchで自己重複テンソルを使用することが100％安全であった時期はわかりませんが、一般の人々が使用するのはそうではないという印象があります。

はい。そうするプログラムはすべて、エラーとして合理的に分類される可能性があります。 私は、これらのフラグについて思いついた契約を文書化するように注意する必要があることを意味しました。

外部ライブラリに関する限り、これがベストエフォートであり、問​​題を知るときに警告を追加することを明確に述べる必要があると思います...

ドキュメントは、「非決定論的であることが知られている数学ライブラリ呼び出し...」のようなものを言うかもしれませんか？

私は@ t-viに同意します（そして、報告された非決定性の半分が後方にアップスケーリングしているという観察が本当に好きです）。 特に、非決定論的であることが知られている関数を部分的に文書化した（または決定論的であると一部の関数を部分的に文書化した）状態は、まったく何も示さない状態よりも厳密に優れていると思います-重要なこと私たちがサポートしていないことをサポートすると主張しないことです！ 決定論のテストをどのように行うことができるかを考えることは有用な活動であることに同意しますが、これは明らかに非決定論的であるAPIにフラグを立てるのと直交する活動だと思います。

たくさんのアイデアが浮かんできたので、それらのいくつかについての私の具体的な考えを紹介します。

1. 「おそらく、カテゴリー3の機能のリストを維持することも考えられるでしょう。」 これは大変な作業のようです。 おそらく、決定論のためにいくつかの調整を明示的に行った関数（おそらく、決定論的フラグをサポートする関数）に対してのみ価値があると思います。
2. 「すべての関数で決定論テストを実行するCIジョブを設定できる可能性があります。」 このようなことは、その性質上、非決定論的なものをテストしているため、細心の注意を払って行う必要があると思います。つまり、決定論テスト自体が「不安定」です（場合によっては合格し、他の場合は失敗します）。 。 私たちのCIレポートツールは、このような状況をうまく処理しません。
3. 「ただし、2つ目は少し注意が必要です。特に、バージョンやハードウェア間で、oneDNN、cuDNN、MAGMAなどの数学ライブラリの操作が決定論的であるかどうかを判断するのが難しいのではないかと心配しています。」 これに最善を尽くす必要があります。 多くの場合、数学ライブラリは、それらが決定論的であるかどうかをドキュメントで明示的に指定しているため、ドキュメントの内容を忠実に報告する必要があります。
4. 「たぶん、すべてのネイティブの非決定論的操作について警告し、数学ライブラリの呼び出しが行われたときにも警告することができますか？」 私たちはこれをすべきではないと思います。 非決定性について警告するとき、それは非決定性が起こっているからであり、起こっているかもしれないということではありません。 警告しすぎると、人々は警告を無視し始めます。

クロスバージョン/ハードウェアの決定論について心配する必要はないと思います。幸運を祈ります。

非決定性について警告するとき、それは非決定性が起こっているからであり、起こっているかもしれないということではありません。 警告しすぎると、人々は警告を無視し始めます。

トリッキーに見えます。 たとえば、いくつかのopを実行していて、PyTorchの実装が決定論的であるが、一部の拡張機能が（ディスパッチキー、トーチ関数などを介して）何かをオーバーライドし、今はわかりません。 それが実際に私の非決定論の原因である場合、それは警告されないのは残念なことのように思えます。

それが実際に私の非決定論の原因である場合、それは警告されないのは残念なことのように思えます。

もちろんですが、ユーザーが非決定論的なシェナニガンに私たちを関与させることもできません。もちろん、警告を受けることは期待できません;）

フラグAPIが存在し、十分に文書化されているため、この問題を今すぐ解決できると思います。

@kurtamohler素晴らしい仕事。 ありがとう。

つまり、 torch.manual_seed(111)を使用して、 interpolation操作を含むすべてを決定論的に設定できるということですか？

いいえ。再現性/ランダム性に関する注記を
これまでのところ、インフラストラクチャがあり、非決定論に関する既知のソースにマークを付け、ドキュメントを大幅に改善して、何が起こっているのかを知ることができます。
非決定論的な操作を実行した場合でも、運が悪いことになりますが、今ではそれに取り組む方が合理的です。

特に補間は、それほど複雑ではないカーネルを後方に記述することで決定論的にすることができるもののようです。

@ t-viこんにちは、pytorch 1.7がリリースされたので、補間後方カーネルは更新されましたか？

したがって、CUDAアップサンプリングカーネルとバックワードはaten/src/ATen/native/cuda/UpSample*ます。 grepは、線形、双線形、3次が非決定論的な後方（警告マーカーを持っている）を持っていることを示唆していますが、最も近いものは持っていません。
ただし、@ kurtamohlerの方がはるかに良い質問です。