Невоспроизводимость сравнения с плавающей запятой

Можно предположить, что ваши вычисления обычно выполняются с несколькими дополнительными битами точности внутри FPU и округляются только в определенных точках (например, когда вы присваиваете результат значению).

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

Чтобы было ясно: я сомневаюсь, что «оставшиеся» биты могут быть виновниками. Скорее, это будет потеря дополнительных битов, вызывающая округление в немного разных точках вычислений.

Какая платформа?

Большинство FPU могут внутренне сохранять большую точность, чем двойное представление ieee, чтобы избежать ошибки округления в промежуточных результатах. Часто компилятор переключается на обмен скорости/точности — см. http://msdn.microsoft.com/en-us/library/e7s85ffb(VS.80).aspx

Является ли программа многопоточной?

Если да, я бы заподозрил состояние гонки.

В противном случае выполнение программы является детерминированным. Наиболее вероятной причиной получения разных результатов при одних и тех же входных данных является неопределенное поведение, то есть ошибка в вашей программе. Чтение неинициализированной переменной, устаревшего указателя, перезапись младших битов некоторого числа FP в стеке и т. д. Возможности безграничны. Если вы используете это в Linux, попробуйте запустить его под valgrind и посмотрите, обнаружит ли он какие-то ошибки.

Кстати, как вы сузили проблему до сравнения FP?

(Дальний план: сбой оборудования? Например, сбой микросхемы ОЗУ может привести к тому, что данные будут считываться по-разному в разных случаях. Хотя это, вероятно, приведет к довольно быстрому сбою ОС.)

Любое другое объяснение неправдоподобно — ошибки в ОС или аппаратном обеспечении не могли бы долго оставаться незамеченными.

Я сделал это:

#include <stdio.h>
#include <stdlib.h>

typedef long double ldbl;

ldbl x[1<<20];

void hexdump( void* p, int N ) {
  for( int i=0; i<N; i++ ) printf( "%02X", ((unsigned char*)p)[i] );
}

int main( int argc, char** argv ) {

  printf( "sizeof(long double)=%i\n", sizeof(ldbl) );

  if( argc<2 ) return 1;

  int i;
  ldbl a = ldbl(1)/atoi(argv[1]);

  for( i=0; i<sizeof(x)/sizeof(x[0]); i++ ) x[i]=a;

  while(1) {
    for( i=0; i<sizeof(x)/sizeof(x[0]); i++ ) if( x[i]!=a ) {
      hexdump( &a, sizeof(a) );
      printf( " " );
      hexdump( &x[i], sizeof(x[i]) );
      printf( "\n" );
    }
  }

}

скомпилировано с помощью IntelC с использованием /Qlong_double, так что получилось это:

;;;     for( i=0; i<sizeof(x)/sizeof(x[0]); i++ ) if( x[i]!=a ) {

        xor       ebx, ebx                                      ;25.10
                                ; LOE ebx f1
.B1.9:                          ; Preds .B1.19 .B1.8
        mov       esi, ebx                                      ;25.47
        shl       esi, 4                                        ;25.47
        fld       TBYTE PTR [?x@@3PA_TA+esi]                    ;25.51
        fucomp                                                  ;25.57
        fnstsw    ax                                            ;25.57
        sahf                                                    ;25.57
        jp        .B1.10        ; Prob 0%                       ;25.57
        je        .B1.19        ; Prob 79%                      ;25.57
[...]
.B1.19:                         ; Preds .B1.18 .B1.9
        inc       ebx                                           ;25.41
        cmp       ebx, 1048576                                  ;25.17
        jb        .B1.9         ; Prob 82%                      ;25.17

и запустил 10 инстансов с разными "сидами". Как видите, он сравнивает 10-байтовые удвоения из памяти с одним в стеке FPU, поэтому в случае, когда ОС не сохраняет полную точность, мы обязательно увидим ошибку. Ну, они все еще работают, ничего не обнаруживая... что неудивительно, потому что x86 имеет команды для сохранения/восстановления всего состояния FPU сразу, и в любом случае ОС, которая не будет сохранять полную точность, будет полностью сломана .

Таким образом, либо это какая-то уникальная ОС/процессор/компилятор, либо после изменения чего-либо в программе и ее перекомпиляции получаются разные результаты сравнения, либо это ошибка в программе, например. переполнение буфера.

Внутренний FPU ЦП может хранить числа с плавающей запятой с более высокой точностью, чем значения типа double или float. Эти значения должны быть преобразованы всякий раз, когда значения в регистре должны храниться где-то еще, в том числе когда память выгружается в кеш (это я знаю точно), а переключение контекста или прерывание ОС на этом ядре звучит как еще один простой источник . Конечно, синхронизация прерываний ОС, переключений контекста или подкачки негорячей памяти совершенно непредсказуема и не контролируется приложением.

Конечно, это зависит от платформы, но ваше описание звучит так, будто вы работаете на современном рабочем столе или сервере (то есть x86).

Я просто объединим некоторые комментарии Дэвида Родригеса и Бо Перссона и сделаю дикое предположение.

Может ли это быть переключение задач при использовании инструкций SSE3? На основании этого статья Intel об использовании инструкций SSE3, команды для сохранения состояния регистра FSAVE и FRESTOR были заменены на FXSAVE и FXRESTOR, которые должны обрабатывать всю длину аккумулятора.

Я предполагаю, что на машине x64 "неправильная" инструкция может содержаться в какой-то внешней скомпилированной библиотеке.

Вы наверняка столкнулись с ошибкой GCC № 323, которая, как и другие моменты, out происходит из-за избыточной точности FPU.

Решения:

• Использование SSE (или AVX, это 2016 год...) для выполнения ваших вычислений
• Использование переключателя компиляции -ffloat-store. Из документов GCC.

Не храните переменные с плавающей запятой в регистрах и запрещайте другие параметры, которые могут повлиять на выбор значения с плавающей запятой из регистра или памяти.
Этот параметр предотвращает нежелательную избыточную точность на таких машинах, как 68000, где используются регистры с плавающей запятой. (из 68881) сохраняют большую точность, чем должен иметь двойник. Аналогично для архитектуры x86. Для большинства программ избыточная точность идет только на пользу, но некоторые программы полагаются на точное определение IEEE с плавающей запятой. Используйте -ffloat-store для таких программ после их модификации для сохранения всех соответствующих промежуточных вычислений в переменных.