Почему процессор Intel Haswell XEON периодически неправильно вычисляет FFT и ART?

В последние дни я наблюдал за поведением своего нового рабочего места, которое не мог объяснить. Проведя небольшое исследование этой проблемы, возможно, есть ошибка в архитектура INTEL Haswell, а также в текущем поколении Skylake.

Прежде чем писать о возможной ошибке, позвольте мне дать вам обзор используемого оборудования, программного кода и самой проблемы.

Спецификация оборудования рабочей станции

• INTEL Xeon E5-2680 V3 2500 МГц 30 МБ кэш-памяти 12 ядер
• Supermicro SC745 BTQ -R1K28B-SQ
• 4 x 32 ГБ ECC Registered DDR4-2133 Ram
• Твердотельный накопитель INTEL серии 730 480 ГБ
• NVIDIA Тесла C2075
• NVIDIA ТИТАН

Операционная система и программный код, о котором идет речь

В настоящее время я использую 64-битную настольную версию Ubuntu 15.04, установлены последние обновления и ядро. Помимо использования этой машины для разработки ядер CUDA и прочего, я недавно протестировал чистую программу C. Программа выполняет своего рода модифицированное ART на довольно больших входных наборах данных. Таким образом, код выполняет некоторые БПФ и требует довольно много времени для завершения вычислений. В настоящее время я не могу публиковать / ссылаться на какой-либо исходный код, так как это текущее исследование, которое не может быть опубликовано. Если вы не знакомы с ART, просто объясните, что он делает. ART - это метод, используемый для восстановления данных, полученных с компьютерного томографа, для получения видимых изображений для диагностики. Таким образом, наша версия кода восстанавливает наборы данных размером, например, 2048x2048x512. До сих пор в этом не было ничего особенного, ни ракетостроения. После нескольких часов отладки и исправления ошибок код был протестирован на эталонных результатах, и мы можем подтвердить, что код работает так, как должен. Единственная библиотека, которую использует код, - это стандартная math.h. Никаких специальных параметров компиляции, никаких дополнительных библиотечных вещей, которые могут вызвать дополнительные проблемы.

Наблюдая за проблемой

Код реализует ART, используя метод минимизации проекций, необходимых для восстановления данных. Итак, давайте предположим, что мы можем восстановить один фрагмент данных, включающий 25 проекций. Код запускается с точно такими же входными данными на 12 ядрах. Обратите внимание, что реализация не основана на многопоточности, на данный момент запущено 12 экземпляров программы. Я знаю, что это не лучший способ сделать это, настоятельно рекомендуется правильное управление потоками, и это уже в списке улучшений :)

Поэтому, когда мы запускаем по крайней мере два экземпляра программы (каждый экземпляр работает с отдельным срезом данных), результаты некоторых прогнозов случайным образом ошибочны. Чтобы получить представление о результатах, см. Таблицу 1. Обратите внимание, что входные данные всегда одни и те же.

Запуск только одного экземпляра кода с участием одного ядра ЦП, все результаты верны. Даже при выполнении некоторых прогонов с использованием одного ядра ЦП результаты остаются правильными. Только при включении хотя бы двух или более ядер генерируется шаблон результата, как показано в Таблице 1.

Выявление проблемы

Хорошо, потребовалось несколько часов, чтобы понять, что на самом деле идет не так. Итак, мы просмотрели весь код, большинство этих проблем начинаются с незначительной ошибки реализации. Но нет (конечно, мы не можем ни доказать отсутствие ошибок, ни гарантировать это). Для проверки нашего кода мы использовали две разные машины:

• (Machine1) Четырехъядерный процессор Intel Core i5 (модель конца 2009 г.)
• (Machine2) Виртуальная машина, работающая на 6-ядерном процессоре Intel XEON SandyBridge

удивительно, что и Machine1, и Machine2 дают всегда правильные результаты. Даже при использовании всех процессорных ядер результаты остаются правильными. Ни одного неверного результата из более чем 50 запусков на каждой машине. Код был скомпилирован на каждой целевой машине без параметров оптимизации или каких-либо конкретных настроек компилятора. Итак, чтение новостей привело к следующим выводам:

• ArsTechnika - ЦП Skylake зависает при сложной нагрузке
• PcWorld - как чтобы проверить свой компьютер на наличие ошибок Skylake
• Сообщество Intel - просто инструкция по заморозке процессора Skylake

Итак, ребята из Prime95 и Сообщество Мерсенна кажется первым, кто обнаружит и определит это неприятный баг. Упомянутые сообщения и новости подтверждают подозрение, что проблема существует только при большой нагрузке. Следуя своим наблюдениям, я могу подтвердить такое поведение.

Вопросы)

• Наблюдали ли вы / сообщество эту проблему на процессорах Haswell, а также на процессорах Skylake?
• Поскольку gcc выполняет оптимизацию AVX (2) по умолчанию (когда это возможно), отключение этой оптимизации поможет?
• Как я могу скомпилировать свой код и убедиться, что любая оптимизация, на которую может повлиять эта ошибка, отключена? Пока я читал только о проблеме с использованием набора команд AVX2 в архитектурах Haswell / Skylake.

Решения?

Хорошо, я могу отключить все оптимизации AVX2. Но это замедляет мой код. Intel может выпустить обновление BIOS для производителей материнских плат, которое изменит микрокод в процессорах Intel. Поскольку это кажется аппаратной ошибкой, это может стать интересным даже при обновлении микрокода ЦП. Я думаю, что это может быть допустимый вариант, поскольку процессоры Intel используют некоторые механизмы преобразования RISC в CISC, контролируемые микрокодом.

РЕДАКТИРОВАТЬ: Techreport.com - Исправление побуждает Intel отключить TSX в Haswell, ранних процессорах Broadwell Будет проверять версию микрокода в моем процессоре.

EDIT2: На данный момент (19.01.2016 15:39 CET) Memtest86 + v4.20 работает и тестирует память. Поскольку это, похоже, займет некоторое время, завтра я обновлю сообщение с результатами.

EDIT3: На данный момент (21.01.2016 09:35 CET) Memtest86 + завершил два прогона и прошел. Ни одной ошибки памяти. Обновлен микрокод процессора с revision=0x2d до revision=0x36. В настоящее время готовим исходный код к выпуску здесь. Состоит проблема с неправильными результатами. Поскольку я не являюсь автором рассматриваемого кода, я должен дважды проверить, чтобы не размещать код, который мне не разрешен. Я также использую рабочую станцию ​​и обслуживаю ее.

EDIT4: (22.01.2016) (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)