bfloat16

[vak]

Полезная шпаргалка от Интела: bf16-hardware-numerics-definition-white-paper.pdf

Описывает подробности реализации чисел с плавающей точкой в формате BFloat16, или для краткости BF16.

BF16 отличается от стандартного FP32 (известного в Си как float) несколькими моментами.

• Размер мантиссы уменьшен с 23 бит до 7 бит.
• Размер экспоненты остаётся тот же, 8 бит.
• Денормализованное число на входе операции считается нулём.
• Денормализованный результат сбрасывается в ноль.
• Результат округляется до ближайшего чётного.
• Inf и NaN поддерживаются как обычно.
• Никаких исключений или прерываний. В частности, SNaN не вызывает исключения.

Comments

[spamsink]

Смешно, что я узнал о существовании bf16 буквально несколько часов назад на рабочем совещании.

[vak]

Про MSFP не упоминали на совещании? :)
Тоже есть такой формат плавающей точки, перспективный для AI.

https://proceedings.neurips.cc/paper/2020/file/747e32ab0fea7fbd2ad9ec03daa3f840-Paper.pdf

[spamsink]

Так ведь bfloat16 в DSP уже реализован, а когда MSFP в каком-нибудь хардвере будет, тогда и будем посмотреть. :)

[vit_r]

Исключения и прерывания убрали для того, чтобы ничто не мешало гнать лажу?

[ivanrubilo]

Лажу можно и раньше было гнать с QNan.
Теперь программа сама должна проверять результат, без вот этого всего финта ушами в мир PDP-11 и обратно.

[vit_r]

Но мы-то знаем, что никто проверять результат не будет.

[ivanrubilo]

Так и SIGFPE небось тоже игнорили и результат получался всё равно NaN.

[vit_r]

Игнор специально и игнор по дефолту несколько отличается. Но, да. Сейчас ошибки игнорировать будет гораздо быстрее.

[waqur]

Невозбранно гнать лажу можно уже довольно давно: например, в gcc/clang для целевой архитектуры x86_64 по умолчанию активна опция -mfpmath=sse, что отключает использование старых регистров и инструкций FPU, соответствующие аппаратные исключения, SIGFPE, установку errno при FPU-ошибках и прочие доисторические глупости. Ну и попутно обеспечивает long double = double. Довольно много старых аппаратных фич такого рода сейчас не используется, например тот же синус вычисляется всегда на основе табличных данных в libm/libgcc_s, современный компилятор практически невозможно заставить сгенерировать инструкцию FSIN (только через ассемблерную вставку) — т.к. эта инструкция невыгодна ни по скорости, ни по точности. Поэтому её SIMD-варианта не существует.

[vit_r]

Помнится, рассказывали, что учёные в одном институте обнаружили, что в компиляторе фортрана есть ключик "быстро" и есть ключик "точно". И первый стоит по умолчанию.

[euthanasepam]

С какой версии?

[waqur]

Точно не знаю, но это поведение описано в документации: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
см. "-mfpmath=unit", ‘sse’: For the x86-64 compiler, these extensions are enabled by default.

(так что, подозреваю, с самой первой версии компилятора, в которой появилась поддержка целевой архитектуры x86_64).

Если подумать, то это ведь часть ABI. Если, например, функция принимает аргумент типа double, то его надо передавать либо в регистре st(0), либо в регистре XMM0. Соответственно, есть какой-то вариант, принятый для данной целевой архитектуры по умолчанию (для i686 это st(0) а для x86_64 это XMM0), а если пользователь начинает задавать какие-то нестандартные флаги компиляции для данной единицы трансляции, например играться с -mfpmath, то компилятору нужно вставить инструкцию выгрузки аргумента в другой регистр при вызове функции из другого модуля, или по указателю. Во-первых, это лишняя трата времени выполнения. Во-вторых, такие вещи нельзя легко изменить в новой версии компилятора, их закладывают раз и навсегда, как часть ABI, при добавлении в компилятор поддержки новой целевой архитектуры.

[euthanasepam]

Похоже, что так. Беглое гугление показывает, что подобные вопросы задавали [и ответы на них давали] ещё начале нулевых, то есть именно по выходу потребительской AMD64.

[ivanrubilo]

Уже bf8 на подходе.

[archaicos]

BFF! :)

[vak]

Круче всего BFG 9000.

[spamsink]

Лишь бы на разных континентах не было разных вариантов, как с A-law и μ-law.

[ivanrubilo]

Да уже некоторые наклепали - у кого-то -0 - это NaN, у кого-то что-то другое...