Почему Intel Haswell XEON CPU спорадически ошибочно вычисляет БПФ и АРТ?

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

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

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

INTEL Xeon E5-2680 V3 2500MHz 30M Cache 12Core
Supermicro SC745 BTQ -R1K28B-SQ
4 x 32 ГБ ECC зарегистрирован DDR4-2133 Ram
INTEL SSD 730 Series 480 ГБ
NVIDIA Tesla C2075
NVIDIA TITAN

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

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

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

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

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

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

Идентификация проблемы

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

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

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

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

Вопрос (ы)

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

Решения?

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

EDIT: Techreport.com - Исправление запроса Intel отключить TSX в Haswell, ранних процессорах Broadwell Будет проверять версию микрокода в моем процессоре.

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

EDIT3: На данный момент (21.01.2016 09:35 CET) Memtest86 + закончил два прохода и прошел. Даже одна ошибка памяти. Обновлен микрокод CPU от 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)

Ответ 1

EDIT: проблема решена. Я должен выкрикнуть огромную извините за сообщество и большое спасибо за ваши намеки. Извините анонимного пользователя, который, похоже, участвует в разработке ядра. Что случилось? Мы провели еще 2 дня отладки и возились с программным кодом. Никаких проблем с реализацией не обнаружено. НО: основной код включает другую вспомогательную программу. Эта вспомогательная программа рассчитывает весы для алгоритма ART по требованию. Поэтому после отладки и тестирования эта вспомогательная программа испортилась, при запуске не менее 4 процессов. Таким образом, это не было проблемой ядра/оборудования, а проблемой программного обеспечения (доступа к памяти).

Извлеченные уроки:

Отладить все инструменты, вовлеченные в процесс расчета.
Микрокод устарел. Об этом сообщается SuperMicro.
Ubuntu 15.04, возможно, потребует дополнительных инструментов, чтобы все ядра процессора работали на полной скорости. Достигнуто это, установив Ubuntu 14.04 - все ядра работают на частоте 2,5 ГГц.
Мне нужно потратить немного пива, если мы когда-нибудь встретимся на конференции.

Итак, после трех дней размышлений, тестирования и возиться с машиной, я обнаружил следующие наблюдения сегодня:

Ubuntu 15.04 запускает процессор с частотой 420 - 650 МГц на ядро. Хорошо, я думал, что это вариант с энергосбережением, поэтому я следил за различными направляющими, чтобы установить максимальную скорость (2,50 ГГц). Это не сработало. Проверено с помощью cpufreq-utils.
Результаты остались неподходящими после нескольких тестов на этой машине. Другие (i5, i7, XEON) машины дали правильные результаты.
Я читал, что другие пользователи столкнулись с проблемами с Ubuntu 15.04 и частотой процессора. Поэтому я решил подключить SSD и установить Ubuntu 14.04. Еще раз проверьте, какая частота процессора сейчас... и она показала 2,50 ГГц, как я и ожидал.
Снова начался алгоритм реконструкции (который теперь был в 4-5 раз быстрее, чем на Ubuntu 15.04) и ждал результатов. Хорошо. Результаты правильные! Я дважды проверил, запустил 9 процессов и сравнил результаты. Верно.

Поэтому я могу только предположить, что в Ubuntu 15.04/kernel может возникнуть проблема с использованием Speedstep в этом CPU. Процессор в 15.04 работал все время между 420 - 650 МГц, в то время как минимальная частота процессора должна составлять 1,20 ГГц, а максимальная частота процессора составляет 3,30 ГГц. Если кто-то хочет проверить, я могу предложить исходный код и примеры данных, ведущих к этой проблеме.

Извините, что подозревал, что это ошибка процессора.

ИЗМЕНИТЬ: после некоторого тестирования, проблема решена только для некоторых сценариев, но еще не для всех. Я сделаю больше тестов.

Ответ 2

Ошибка Skylake-S/U prime95 находится в модуле AVX (не AVX2). Он фиксируется на микрокодах 0x56 (вероятно) и 0x6a (наверняка). Такой недостаток в Хасуэлл маловероятен, но возможен (особенно на Intel после 2014 года, где "валидация" стала нежелательной стоимостью вместо арендатора за качество).

Haswell имеет ошибки, связанные с устройством AVX, хотя HSE58 вряд ли будет играть (это только замедляет работу блока AVX). Однако перед установкой AVX2 попытайтесь поместить несколько инструкций MFENCE. Если это исправлено, немедленно сообщите об этом, это значит, что нам нужно MFENCE все IRET в ядре (HSE105).

У вашего процессора есть подпись 0x306f2. Убедитесь, что у вас есть версия микрокода 0x36 или новее, этот микрокод находится в пакете обновления для микрокода Linux от Intel Intel® с пакетом обновления до 2015-11-06.

EDIT: на самом деле это был не ответ, поэтому я должен был сделать это замечанием. Я приношу извинения. Поскольку обновление микрокода было недостаточным для исправления проблемы, оно все равно может быть новой ошибкой, старой, но необработанной ошибкой или чем-то еще полностью (например, ошибкой кода или ошибкой генерации кода gcc).