数日前、新しいワークステーションで説明できない動作を観察しました。この問題について調査したところ、INTEL Haswellアーキテクチャ現在の Skylake 世代でも同様です。
起こりうるバグについて書く前に、使用されているハードウェア、プログラム コード、および問題自体の概要を説明します。
ワークステーションのハードウェア仕様
- INTEL Xeon E5-2680 V3 2500MHz 30M キャッシュ 12 コア
- スーパーマイクロ SC745 BTQ -R1K28B-SQ
- 4 x 32GB ECC 登録済み DDR4-2133 ラム
- INTEL SSD 730 シリーズ 480 GB
- NVIDIA テスラ C2075
- NVIDIA タイタン
問題となっているオペレーティング システムとプログラム コード
私は現在、Ubuntu 15.04 64ビットデスクトップ版を実行しており、最新のアップデートとカーネルがインストールされています。このマシンを使用してCUDAカーネルなどを開発するほか、最近純粋なCプログラムをテストしました。このプログラムは、美術かなり大きな入力データセットに対してです。そのため、コードはいくつかのFFTを実行し、計算を完了するのにかなりの時間がかかります。これは進行中の研究であり、公開できないため、現在ソースコードを投稿したりリンクしたりすることはできません。美術、それが何をするのかを簡単に説明します。ARTは、コンピュータ断層撮影装置から受信したデータを再構成して、診断用の可視画像を取得するために使用される技術です。したがって、私たちのバージョンのコードは、2048x2048x512のようなサイズのデータセットを再構成します。これまでのところ、特別なことやロケット科学的なことは何も関係ありません。数時間のデバッグとエラーの修正の後、コードは参照結果でテストされ、コードが想定どおりに機能することが確認されました。コードが使用するライブラリは標準のみですmath.h。特別なコンパイルパラメータはなく、追加の問題を引き起こす可能性のある追加のライブラリはありません。問題。
問題を観察する
このコードは、データの再構築に必要な投影を最小限に抑える手法を使用して ART を実装します。したがって、25 の投影を含むデータの 1 つのスライスを再構築できると仮定します。コードは、12 個のコアでまったく同じ入力データを使用して開始されます。実装はマルチスレッドに基づいていないことに注意してください。現在、プログラムの 12 個のインスタンスが起動されます。これが最善の方法ではないことはわかっていますが、適切なスレッド管理を行うことが強く推奨されており、これはすでに改善リストに含まれています :)
したがって、プログラムのインスタンスを少なくとも 2 つ実行すると (各インスタンスは別々のデータ スライスで動作します)、一部の投影の結果はランダムに間違っています。結果の概要については、表 1 を参照してください。入力データは常に同じであることに注意してください。
CPU の 1 つのコアを含むコードのインスタンスを 1 つだけ実行すると、結果はすべて正しくなります。CPU の 1 つのコアを含む実行をいくつか実行しても、結果は正しいままです。少なくとも 2 つ以上のコアを含むと、表 1 に示すような結果パターンが生成されます。
問題の特定
さて、実際に何が問題なのかを把握するのにかなりの時間がかかりました。そこで、コード全体を確認したところ、これらの問題のほとんどは、小さな実装ミスから始まっています。しかし、そうではありません (もちろん、バグがないことを証明したり保証したりすることはできません)。コードを検証するために、2 つの異なるマシンを使用しました。
- (マシン1) Intel Core i5 クアッドコア (2009 年後半のモデル)
- (マシン2) Intel XEON 6コア SandyBridge CPU 上で動作する仮想マシン
驚くべきことに、マシン1とマシン2の両方がいつも正しい結果が得られました。すべての CPU コアを使用しても、結果は正しいままです。すべてのマシンで 50 回以上実行しても、間違った結果は 1 つもありませんでした。コードは、最適化オプションや特定のコンパイラ設定なしで、すべてのターゲット マシンでコンパイルされました。そこで、ニュースを読むと、次のことがわかりました。
- ArsTechnika - 複雑なワークロード中に Skylake CPU がフリーズする
- PcWorld - PC の Skylake バグをテストする方法
- Intel コミュニティ - Skylake プロセッサをフリーズするための簡単な手順
そこで、プライム95そしてそのメルセンヌコミュニティこれを最初に発見し特定したと思われる厄介なバグ参照された投稿とニュースは、この問題は負荷が高い場合にのみ発生するという疑いを裏付けています。私の観察によれば、この動作を確認できます。
質問）
- あなたやコミュニティは、Haswell CPU だけでなく Skylake CPU でもこの問題を観察しましたか?
- gcc はデフォルトで AVX(2) 最適化 (可能な場合) を実行するので、この最適化をオフにすると役立ちますか?
- どうすればコードをコンパイルして、どれでもこのバグの影響を受ける可能性のある最適化はオフになっていますか? これまでのところ、Haswell / Skylake アーキテクチャで AVX2 コマンド セットを使用する際の問題についてのみ読みました。
解決策は?
わかりました。すべての AVX2 最適化をオフにできます。ただし、これによりコードの速度が低下します。Intel は、Intel CPU のマイクロコードを変更する BIOS アップデートをマザーボード製造元にリリースする可能性があります。これはハードウェア バグのようですので、CPU のマイクロコードを更新することでも興味深いものになる可能性があります。Intel CPU はマイクロコードによって制御される RISC から CISC への変換メカニズムを使用しているため、これは有効なオプションであると思います。
編集：Techreport.com - エラッタによりインテルは Haswell および初期の Broadwell CPU で TSX を無効にするよう指示CPU のマイクロコードのバージョンを確認します。
編集2: 現在 (2016 年 1 月 19 日 15:39 CET)、Memtest86+ v4.20 が実行され、メモリがテストされています。完了するまでにかなり時間がかかるようなので、明日結果を投稿で更新します。
編集3: 現時点では (2016 年 1 月 21 日 09:35 CET)、Memtest86+ は 2 回実行して合格しました。メモリ エラーは 1 つもありません。CPU のマイクロコードを から に更新しましたrevision=0x2d。revision=0x36現在、ここでリリースするためのソース コードを準備しています。間違った結果の問題があります。問題のコードの作成者は私ではないので、許可されていないコードを投稿しないように二重チェックする必要があります。ワークステーションも使用して保守しています。
編集4: (2016 年 1 月 22 日) (12:15 CET) ソースコードをコンパイルするために使用する Makefile は次のとおりです。
# VARIABLES ==================================================================
CC = gcc
CFLAGS = --std=c99 -Wall
#LDFLAGS = -lm -lgomp -fast -s -m64
LDFLAGS = -lm
OBJ = ArtReconstruction2Min.o
# RULES AND DEPENDENCIES ====================================================
# linking all object files
all: $(OBJ)
$(CC) -o ART2Min $(OBJ) $(LDFLAGS)
# every o-file depends on the corresonding c-file, -g Option bedeutet Debugging Informationene setzen
%.o: %.c
$(CC) -c -g $< $(CFLAGS)
# MAKE CLEAN =================================================================
clean:
rm -f *.o
rm -f main
出力は次のようになりますgcc -v。
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
ベストアンサー1
編集: 問題は解決しました。コミュニティに心からお詫び申し上げます。また、ヒントをくださった方々に心から感謝いたします。カーネル開発に関わっていると思われる匿名のユーザーには申し訳ありません。何が起こったのでしょうか? プログラム コードのデバッグと調整にさらに 2 日間費やしました。実装上の問題は見つかりませんでした。ただし、メイン コードには別のヘルパー プログラムが含まれています。このヘルパー プログラムは、ART アルゴリズムの重みをオンデマンドで計算します。デバッグとテストを行った後、このヘルパー プログラムは、少なくとも 4 つのプロセスを実行すると、エラーを起こしました。つまり、これはカーネル/ハードウェアの問題ではなく、ソフトウェア (メモリ アクセス) の問題でした。
学んだ教訓：
- 計算プロセスに関係するすべてのツールをデバッグします。
- マイクロコードが古くなっています。SuperMicro にこのことが通知されました。
- Ubuntu 15.04 では、CPU のすべてのコアがフルスピードで動作するように、追加のツールが必要になる可能性があります。これは、Ubuntu 14.04 をインストールすることで実現しました。すべてのコアが 2.5GHz で動作します。
- 会議で会うことがあったら、ビールを少し飲まなければなりません。
そこで、3日間考え、テストし、マシンをいじくり回した後、今日、次のことに気付きました。
Ubuntu 15.04 は、CPU をコアあたり 420 - 650 MHz で実行します。これは省電力オプションだと思ったので、さまざまなガイドに従って速度を最大 (2.50 GHz) に設定しました。うまくいきませんでした。 で確認しました
cpufreq-utils。このマシンで数回テストした後も、結果は依然として間違っていました。他のマシン (i5、i7、XEON) では正しい結果が得られました。
他のユーザーが Ubuntu 15.04 と CPU 周波数に関する問題を経験したと読みました。そこで、SSD を接続して Ubuntu 14.04 をインストールすることにしました。CPU 周波数が現在何であるかを再度確認すると、予想どおり 2.50 GHz を示しました。
再度、再構築アルゴリズムを開始し (Ubuntu 15.04 よりも 4 ～ 5 倍高速になりました)、結果を待ちました。わかりました。結果は正しくなりました。二重チェックを行い、9 つのプロセスを開始して結果を比較しました。それでも正しいです。
したがって、この CPU で Speedstep を使用する Ubuntu 15.04 / カーネルに問題があるとしか考えられません。15.04 の CPU は常に 420 - 650 MHz の間で動作していましたが、最小 CPU 速度は 1.20 GHz と予想され、最大 CPU 速度は 3.30 GHz です。確認を希望される方がいらっしゃれば、この問題の原因となったソース コードとサンプル データを提供できます。
CPUのせいだと疑ってごめんなさいバグ。
編集: さらにテストを行った結果、問題は一部のシナリオでのみ解決されましたが、まだすべてのシナリオで解決されたわけではありません。さらにテストを実施します。