correct

Угу, взял и устроил проверку виртуальной машины в процессоре.
F00F/DIV вроде так фейлы назывались?

Ну это пентиум. Я вот недавно писал программу на C для численного моделирования, и результат различался на интел и АМД, хотя это мог быть UB.

Нашёл в закромах Родины интернетов старый тест

Унеси обратно.

Не знаю насколько сегодня реально встретить CPU с бажной математикой

Его и 20 лет назад было уже нереально встретить.

но на всякий случай портанул

«Поздравляю тебя, Шарик, ты балбес» ©
Кого ты куда портанул, болезный? Твой тест не работает по причине отсутствия в нём инструкции fdiv.

Занялся бы чем-нибудь полезным.

Скорее оптимизация компилятора, при использовании O3 снижается точность вычислений чисел с плавающей точкой, но значительно повышается скорость вычеслений.

Ofast скорее

O3 обязан следовать спецификациям IEEE по мат. функциям, а вот Ofast уже нет

O2 было.

Не знаю насколько сегодня реально встретить CPU с бажной математикой

На ибее полно. 40 баксов и он твой.

хз зачем портировать, когда баги на поверхности
баги с float по прежнему существуют

в одном из вложенных рекурсий или циклов:
1/1!=(float)1
0/0!=+0
0/0!=-0
^баги в том что в верхних уровнях рекурсий/циклов эти условия верны, в нижних они не всегда верны(в 50% случаев через раз) и чем больше проверок тем реже оно верно
куууууууча багов в std::min max mod pow и прочих

баги уровня первого курса универа, и встречаются при написании чего угодно сложнее хеловорда
можно посмотреть исходники вебкита(самого движка, там два файла) как там обходят баги с флоатом

Это же фича. Float как бы вещественные числа, но в реальности разумеется точность их хранения конечная.

Результаты вычислений с float'ом, да, мне определённо не нравятся. Правда, я это списывал на погрешность алгоритмов округления функции printf().

А так, да, помню старое предупреждение учебника, что лучше вместо float'а использовать везде и всегда именно double. Теперь, кажется, всё начинает вставать на свои места.

Ты хоть бы в вики почитал про pentium fdiv bug

Нужно просто не использовать == с числами с плавающей точкой.

При чем тут баги процессора и точность представления фп-чисел?

Я читал, что писал автор теста. И он написал, что этот баг затрагивал не только «single-precision» вычисления, но и «double-precision divides». Именно поэтому я ни секунды не сомневался в том, чтобы в итоге оставить именно double, а не float.

There are some rare cases when the Pentium chip divides two floating-point numbers in which it returns an answer that is slightly inaccurate (the precision of the result is less than expected). The bug affects both single-precision and double- precision divides. It does not appear to effect any other instruction in the processor.

The bug occurs only for certain pairs of numbers. It is repeatable--i.e. if a pair of numbers is known to be affected by the bug, the pair will be affected every time it is tested on every chip with the bug. The bug is also independent of the speed of the chip and any previously executed instructions. ... The Pentium (along with every other major microprocessor) uses the IEEE 754 standard to represent floating point numbers. A floating- point number stores a real number as sign*1.XXX*2^YYY, i.e. one plus a fraction, raised to a power of two, along with the sign. The XXX part is the mantissa and the YYY part is the exponent.

The IEEE standard defines a single-precision number to have a 23-bit mantissa. This provides 24-bit precision (counting the leading one) and is equal to approximately 7 decimal digits. A double precision number has a 52 bit mantissa, giving 53-bit precision; equal to about 15 decimal digits.

➜  i586bugtest-0.1 ./i586bugtest 
your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241
➜  i586bugtest-0.1 lscpu | grep ^Имя
Имя модели:          Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz

Дома еще на fx8320e проверю, говорят это серия отбраковки.

Отбраковывают же по техпроцессу, те по утечкам тока, а не по махровым багам.

Intel(R) Core
fx8320e

Проблема в том, что Pentium FDIV bug работает только на оригинальном пентиуме (и с частотой не выше 100МГц).

i586bugtest

Проблема в том, что Pentium FDIV bug работает только в программах, которые используют эту саму команду fdiv, чего i586bugtest не делает.

ты дебил?
нахера ты занялся ещё и скамом с кликбейтом? охерел совсем уже убогий.

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

Есть вероятность, что миллион макак с печатными машинками напишут войну и мир.

кликбейтом

Шта? Я всегда привожу прямые ссылки. Никаких дополнительных страниц никому никогда открывать не нужно.

При этом есть вероятность, что она может выявляться тем же самым методом

Эта вероятность меньше 1 к количеству кварков во вселенной. Я даже сильно подозреваю, что меньше 1 к числу Грэма.

Сильно подозреваю, что к моменту появления второй точно такой же ошибки, макаки успеют набрать полное собрание сочинений всех трёх Толстых с подстрочными переводами на клингонском и языке хараппской цивилизации.

Ты совсем упорот? Тебе ж русским языком говорят:

• Баг с fdiv был на конкретных моделях ранних первопней
  
• Твой тест его не выявит

Нашёл причину?

Математике всё равно через какие инструкции её вычисляют если в итоге всё равно получается погрешность. Выполнение моего теста позволяет выявить погрешность в делении [конкретных чисел] при её наличии независимо от того через какие инструкции процессора [или что-то другое] она возникает.

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

Мало ли где какая проблема может выявиться.

Хм, но ты-то проверяешь конкретный баг. Который давно исправили.

С тем же успехом можно складывать 2 и 2, и сравнивать результат с константой 4. А то мало ли где на таком вот ровном месте может случиться баг.

но ты-то проверяешь конкретный баг

Нет. Я использую конкретный метод. Реализация которого будучи скомпилена старым компилятором с соответствующими инструкциями на старых первопнях может выявлять известный баг. Но, этот метод более универсален, и может применяться для проверки точности деления двойной точности вообще.

          Intel(R) Pentium(R) CPU G2020 @ 2.90GHz
your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241

          ARMv7 Processor rev 4 (v7l)
your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241

          Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241

          Intel(R) Celeron(R) CPU 1037U @ 1.80GHz
your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241

          Intel(R) Pentium(R) Dual  CPU  T2390  @ 1.86GHz
your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241

И т.д., и т.п.

Это хорошо, что много где хорошая точность вычислений.

Нет. Я и не искал, но похоже на переполнение было. График шел плавно, а затем резкие скачки на несколько порядков, причем на разных процессорах они были в разных местах. Кроме того во входные данные подмешивался рандом, так что причин может быть много.

баги с float по прежнему существуют

Потому что это FLOAT. В логарифмическом представлении многих «багов» нету.

Скачать: http://saahriktu.org/downloads/i586bugtest-0.1.tar.xz

Однострочник?

АХАхххаха

#include <stdio.h>

int main(){
	double y0 = 5505001.0 / 294911.0, y1 = 4195835.0 / 3145727.0;
	printf("your CPU : %.15lf, %.15lf\n", y0, y1);
	printf("correct  : 18.666651972968115, 1.333820449136241\n");
	return 0;
}

AMD Athlon(tm) II X2 270 Processor

your CPU : 18.666651972968115, 1.333820449136241
correct  : 18.666651972968115, 1.333820449136241

Проблема в том, что Pentium FDIV bug работает только на оригинальном пентиуме (и с частотой не выше 100МГц).

Только на самых первых первоначальных пнях с частотой 60/66 МГц и более ни на каких. Абсолютно не вижу ни какого смысла использовать этот тест сейчас. Это не значит, что в более современных процессорах не могут найтись ошибки вычислений, но не fdiv и их пока не нашли.

И кстати, ошибка fdiv на практике проявлялась не всегда, а только для определенных аргументов и не слишком фатальная, просто точность в ее случае была сильно ниже, где-то емнип в 5-6 знаке после запятой. Иначе говоря, нарваться на практически последствия ошибки сложно, хотя конечно для ответственных вычислений использовать бажный fdiv не стоило.

Только на самых первых первоначальных пнях с частотой 60/66 МГц и более ни на каких

Википедия говорит о 10 моделях
https://en.wikipedia.org/wiki/Pentium_FDIV_bug#Affected_models

Автор, ты наркоман. У тебя деление на этапе компиляции происходит.

# ...

_main:
LFB1:
        pushq   %rbp    #
LCFI0:
        movq    %rsp, %rbp      #,
LCFI1:
        subq    $16, %rsp       #,
# i586bugtest.c:4:      double y0 = 5505001.0 / 294911.0, y1 = 4195835.0 / 3145727.0;
        movsd   lC0(%rip), %xmm0        #, tmp89
        movsd   %xmm0, -8(%rbp) # tmp89, y0
        movsd   lC1(%rip), %xmm0        #, tmp90
        movsd   %xmm0, -16(%rbp)        # tmp90, y1
# i586bugtest.c:5:      printf("your CPU : %.15lf, %.15lf\n", y0, y1);
        movsd   -16(%rbp), %xmm0        # y1, tmp91
        movq    -8(%rbp), %rax  # y0, tmp92
        movapd  %xmm0, %xmm1    # tmp91,
        movq    %rax, %xmm0     # tmp92,
        leaq    lC2(%rip), %rdi #,
        movl    $2, %eax        #,
        call    _printf #
# i586bugtest.c:6:      printf("correct  : 18.666651972968115, 1.333820449136241\n");
        leaq    lC3(%rip), %rdi #,
        call    _puts   #
# i586bugtest.c:7:      return 0;
        movl    $0, %eax        #, _6
# i586bugtest.c:8: }
        leave
LCFI2:
        ret
LFE1:
        .literal8
        .align 3
lC0:
        .long   3022370369
        .long   1077062313
        .align 3
lC1:
        .long   477915971
        .long   1073043284
        .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support

# ...

Интересно, не знал, оказывается P75-100 тоже были подвержены...

Гм. Мда уж. Слишком много оптимизаций у современных компиляторов...

http://saahriktu.org/downloads/i586bugtest-0.2.tar.xz

Сочувствую, я тоже вон с числаками страдаю.