为什么英特尔Haswell XEON CPU偶尔会错误地计算FFT和ART？

时间：2016-01-19 09:34:54

标签： intel cpu-architecture processor avx2

在最后几天，我观察到我的新工作站的行为，我无法解释。对此问题进行一些研究，INTEL Haswell architecture以及当前的Skylake Generation可能存在错误。

在写下可能的错误之前，让我先概述一下使用的硬件，程序代码和问题本身。

工作站硬件规范

  • INTEL Xeon E5-2680 V3 2500MHz 30M Cache 12Core
  • Supermicro SC745 BTQ -R1K28B-SQ
  • 4 x 32GB ECC注册DDR4-2133 Ram
  • INTEL SSD 730系列480 GB
  • NVIDIA Tesla C2075
  • NVIDIA TITAN

操作系统＆amp;有问题的程序代码

我目前正在运行Ubuntu 15.04 64位桌面版，安装了最新更新和内核。除了使用这台机器开发CUDA内核和东西，我最近测试了一个纯C程序。 该程序在相当大的输入数据集上进行了一些修改后的ART。因此代码执行一些FFT并耗费相当长的时间来完成计算。我目前无法发布/链接到任何来源 代码，因为这是正在进行的研究，无法发表。如果您不熟悉ART，只需简单解释它的作用。 ART是一种用于重建从计算机断层摄影机接收的数据的技术 可见图像用于诊断。因此，我们的代码版本重建了大小为2048x2048x512的数据集。到目前为止，没有什么特别的，也没有涉及火箭科学。经过几个小时的调试和修复错误后，代码进行了测试 在参考结果，我们可以确认代码按预期工作。代码使用的唯一库是标准math.h。没有特殊的编译参数，没有可能带来额外问题的其他库内容。

观察问题

该代码使用一种技术来实现ART，以最小化重建数据所需的投影。因此，我们假设我们可以重建涉及25个投影的一片数据。代码以12个内核上完全相同的输入数据启动。请注意 实现不是基于多线程，目前启动了12个程序实例。我知道这不是最好的方法，涉及正确的线程管理是很有建议的，这已经在改进列表中了：）

因此，当我们运行至少两个程序实例（每个实例在一个单独的数据切片上工作）时，结果是一些预测是随机的错误。为了让您了解结果，请参阅表1。请注意，输入数据始终相同。

只运行一个涉及CPU核心的代码实例，结果都是正确的。即使执行一些涉及一个CPU内核的运行，结果仍然是正确的。仅涉及至少两个或更多核心会生成结果模式，如表1所示。

Table1: randomly wrong results from Haswell XEON CPU

识别问题

好的，花了几个小时的时间来了解究竟出了什么问题。所以我们完成了整个代码，大多数问题都是以一个小的实现错误开始的。但是，嗯，没有（当然我们不能证明没有错误也不能保证它）。为了验证我们的代码，我们使用了两台不同的机器：

  • （Machine1）英特尔酷睿i5四核（2009年末推出的型号）
  • （Machine2）在Intel XEON 6core SandyBridge CPU上运行的虚拟机
令人惊讶的是，Machine1＆amp; Machine2产生始终正确的结果。即使使用所有CPU核心，结果仍然是正确的。每台机器上超过50次运行甚至没有错误的结果。代码是在没有优化选项或任何特定编译器设置的每台目标机器上编译的。  因此，阅读新闻导致了以下发现：

所以Prime95和Mersenne Community的人似乎是第一批发现并识别此nasty bug的人。引用的帖子和新闻支持怀疑，这个问题只存在于繁重的工作量下。根据我的观察，我可以证实这种行为。

问题

  • 你/社区是否在Haswell CPU以及Skylake CPU上发现了这个问题？
  • 由于gcc根据默认的AVX（2）优化（尽可能），关闭此优化会有所帮助吗？
  • 如何编译我的代码并确保关闭可能受此错误影响的任何优化？到目前为止，我只阅读了使用Haswell / Skylake架构中的AVX2命令集的问题。

解决方案？

好的，我可以关闭所有AVX2优化。但这会减慢我的代码速度。英特尔可能会向主板制造商发布BIOS更新，以更新英特尔CPU中的微码。由于它似乎是一个硬件错误，即使更新CPU微码也可能会变得有趣。我认为这可能是一个有效的选择，因为Intel CPU使用一些由Microcode控制的RISC到CISC转换机制。

编辑：Techreport.com - Errata prompts Intel to disable TSX in Haswell, early Broadwell CPUs将检查我的CPU中的微码版本。

EDIT2：截至目前（19.01.2016 15:39 CET）Memtest86 + v4.20正在运行并测试内存。由于这似乎需要一段时间才能完成，我明天会用结果更新帖子。

EDIT3：截至目前（2016年1月21日09:35 CET）Memtest86 +完成了两次运行并通过了。甚至没有一个内存错误。将CPU的微码从revision=0x2d更新为revision=0x36。目前准备在此发布的源代码。错误结果的问题在于。由于我不是相关代码的作者，我必须仔细检查不发布我不允许的代码。我也在使用工作站并进行维护。

EDIT4：（2016年1月22日）（欧洲中部时间12:15）这里是用于编译源代码的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)

2 个答案:

答案 0 :(得分：7)

编辑：问题解决了。我必须向社区大声抱歉，并非常感谢您的提示。很抱歉用户匿名，他似乎参与了内核开发。发生了什么？我们花了两天时间调试和摆弄程序代码。没有发现任何实施问题。但是：主要代码涉及另一个帮助程序。该帮助程序根据需要计算ART算法的权重。因此，在调试和测试之后，当运行至少4个进程时，这个帮助程序搞砸了。所以这不是内核/硬件问题，而是软件（内存访问）问题。

经验教训：

  1. 调试计算过程中涉及的每个工具。
  2. 微代码已过时。 SuperMicro被告知此事。
  3. Ubuntu 15.04可能需要其他工具，以便CPU的所有内核全速运行。通过安装Ubuntu 14.04实现了这一目标 - 所有核心都运行在2.5GHz。
  4. 如果我们在会议上见面，我需要喝点啤酒。

    5. 因此，经过三天思考，测试和摆弄机器后，我今天发现了以下观察结果：

    1. Ubuntu 15.04以每个内核420 - 650 MHz运行CPU。好吧我认为这是一个节能选项，所以我按照各种指南将速度设置为最大值（2.50 GHz）。它没用。选中cpufreq-utils。

    2. 在此机器上进行多次测试后，结果仍然存在问题。其他（i5，i7，XEON）机器产生了正确的结果。

    3. 我读到其他用户遇到过Ubuntu 15.04和CPU频率问题。所以我决定插入一个SSD并安装Ubuntu 14.04。再次检查现在的CPU频率是什么......它显示了我预期的2.50 GHz。

    4. 再次启动重建算法（现在比Ubuntu 15.04快4-5倍）并等待结果。好的。结果现在正确！我仔细检查，启动了9个流程并比较了结果。还是正确的。

      5. 所以我只能假设在这个CPU中使用Speedstep的Ubuntu 15.04 /内核可能存在问题。 15.04中的CPU始终在420 - 650 MHz之间运行，而最小CPU速度预计为1,20 GHz，最大CPU速度为3,30 GHz。如果有人想要检查，我可以提供导致此问题的源代码和示例数据。

      很抱歉怀疑这是一个CPU 错误。

      编辑：经过一些更多的测试，问题只在某些情况下解决，但尚未解决。我会做更多的测试。

答案 1 :(得分：6)

Skylake-S / U prime95 erratum位于AVX（非AVX2）单元中。它固定在微码0x56（可能）和0x6a（肯定）上。 Haswell中的这种错误是不可能的，但是可能的（特别是在2014年后的英特尔，其中＆＃34;验证＆＃34;成为不受欢迎的成本而非租户的质量）。

Haswell 已将勘误表链接到AVX设备，虽然HSE58不太可能在播放（它只会减慢AVX设备的速度）。但是，请尝试在AVX2计算之前放置一些MFENCE指令。如果这个修复它，立即报告，这意味着我们需要MFENCE内核中的所有IRET（HSE105）。

您的处理器有签名0x306f2。确保您具有微码修订版0x36或更高版本，此微码位于英特尔＆＃34; Linux微码更新包＆＃34;从2015-11-06。

编辑：这不是回答，所以我应该把它作为评论。我道歉。由于微代码更新不足以解决问题，它仍然可能是一个新的勘误表，一个旧的，但没有工作的勘误表，或完全不同的东西（如代码错误或gcc代码生成错误）。

相关问题
最新问题