1

TESLA C2075 を搭載したマシンに pycuda をインストールしました。CUDA-6.0コンパイラがインストールされたUbuntu 14.04で実行しています。

Python 2.7.9 (anaconda ディストリビューション経由) と numpy 1.9.0 を使用して、Andreas Kloeckner が彼の Web サイトで提供している ZIP ファイルから pycuda 2014.1 をインストールしました。( http://mathema.tician.de/software/pycuda/ )

その ZIP ファイルによって提供されるテストを実行すると、ファイルを除いてすべてうまくいきtest_cumath.pyます。次のエラーが表示されます。

E               AssertionError: (2.3841858e-06, 'cosh', <type 'numpy.complex64'>)`
E               assert <built-in method all of numpy.bool_ object at 0x7f00747f3880>()`
E                +  where <built-in method all of numpy.bool_ object at 0x7f00747f3880> = 2.3841858e-06 <= 2e-06.all

test_cumath.py:54: AssertionError`
===== 1 failed, 27 passed in 12.57 seconds =====

この GPU と CPU の cosh の結果の不一致がどこから来るのか、誰か提案がありますか? 2.38e-6 の測定値で 2e-6 の許容範囲をわずかに超えていることは、私には少し奇妙に見えます。特に、他のテストは成功するので…？

4

1 に答える 1

1

GPGPU/CUDA コミュニティでは、ハードウェア プラットフォームと CUDA ライブラリのバージョンが異なると、同じ API を使用しても結果が異なる可能性があることが実際に知られています。違いは常に小さいです。そのため、プラットフォーム間で多少の不均一性があります。

実際、これにより、数値結果に基づいてテストを作成するのが面倒になります。善悪の分類が曖昧になり、「何が十分か」と答えなければなりません。これはクレイジーで、多くの場合問題があり、欠陥があるとさえ考えるかもしれません。ここで異議を唱えるべきではないと思います。

2e-6そもそも許容範囲はどこから来たと思いますか? 誰かが、実際には、十分に正しいと思う分散の量と実際に予想される分散の量との間のトレードオフを見つけようとしたと思います。CPUの世界ではすでに大きいです。したがって、ここでは、GPU プラットフォーム間で予想される程度の不均一性を説明するために、大きな許容範囲を選択した人がいます。2e-6

この場合、実質的には、実際の G​​PU プラットフォームの不均一性を反映するように許容範囲が選択されていないことを意味します。

そうは言っても、GPGPUコミュニティは、信じられないほどの数のGPUカードが不安定な（基本的に壊れている）という事実にも気づいています。本格的なアプリケーションを実行する前に、GPU カードを徹底的にテストする必要があります。特に、GPU カードは再現可能な結果を​​生成する必要があります。変動は壊れたカードの指標です。通常、Tesla は消費者向けカードほど影響を受けませんが、それでも確認されています。同じタイプの 2 枚目の GPU カードがありますか? それは同じ結果を生み出しますか？

GPU カードを (同じタイプの他のカードと比較して) 「壊れている」と特定するか、PyCUDA にバグ レポートを提出して、許容範囲が十分でないことを伝える必要があります。

于 2015-03-03T12:04:47.310 に答える