Войти
ПрограммированиеФорумОбщее

Трюки с float: быстрое вычисление логарифмов. (комментарии) (7 стр)

Страницы: 16 7 8 911 Следующая »
#90
14:01, 15 янв 2022

FordPerfect

Чтобы сломать мой код, достаточно плавучки, отличной от IEEE

Читал, что при обсуждении стандарта самым спорным моментом было введение денормализованных чисел. И время показало, что это было ошибкой: никакой ощутимой пользы они не приносят, но из-за этого все алгоритмы приходится усложнять и иногда замедлять. Вроде даже начали отключать их поддержку. Однако с этим рудиментом теперь придётся жить. На мой взгляд, не нужно также множество различных NaN - они только сокращают диапазон представления чисел. Если требуется передать какой-то код, то, как правило, с тем же успехом его можно представить в виде допустимых чисел или выбрать иной способ передачи. Нужно оставить +-бесконечности и можно оставить один NaN — ту комбинация битов, которая сейчас обозначает -0. А -0, наверное, можно убрать, его польза тоже сомнительная. Либо ввести флаг, что означает эта комбинация битов: -0 или NaN.

Я написал свою длинную арифметику, и решил в ней оставить -0, и не стал делать NaN. Хотя, наверное, лучше наоборот — чтобы проще было сигнализировать о недопустимом аргументе функций.

#91
17:06, 15 янв 2022

Aenigma
> И время показало, что это было ошибкой: никакой ощутимой пользы они не приносят, но из-за этого все алгоритмы приходится усложнять и иногда замедлять.
Нужны денормалы, особенно для чисел с большой мантиссой. Иначе можно неожиданно получить падение точности на несколько порядков на ровном месте. Вот что стоило принять в стандарт — это требование обрабатывать денормалы в железе с той же задержкой, что и нормальные числа.

> На мой взгляд, не нужно также множество различных NaN
А вот два нуля и куча NaN-ов — это, действительно, ошибка. И отдельные бесконечности тоже нафиг нужны. Сделали бы новый стандарт, где −0 → NaN и максимальный порядок — нормальные числа. Он более-менее совместим с текущим (на нормальных числах), но гораздо лучше.

#92
17:21, 15 янв 2022

}:+()___ [Smile]

Иначе можно неожиданно получить падение точности на несколько порядков на ровном месте.

Если падение точности происходит из-за выхода за границы представимого диапазона, когда происходит "антипереполнение", так это естественное явление: не надо работать на границе диапазона, возьми формат с более широким диапазоном порядков или скорректируй алгоритм. Между прочим, денормализованные числа от этой проблемы в сущности не спасают, они её только немного отодвигают. А ещё маскируют. Ты думаешь, что уложился в формат, а на самом деле у тебя кусок мантиссы потерялся, и точность соответственно упала. Вряд ли оправдано незначительное расширение диапазона порядков, достающееся ценой потери точности, иногда существенной.

#93
19:11, 15 янв 2022

Aenigma
> Если падение точности происходит из-за выхода за границы представимого диапазона, когда происходит "антипереполнение", так это естественное явление: не надо работать на границе диапазона, возьми формат с более широким диапазоном порядков или скорректируй алгоритм.
Ценность плавающей точки в том, что не надо специально подгонять диапазоны, а можно запихать то, что есть, и оно "просто работает". А иначе фиксированная точка делает плавающую по всем статьям: и быстрее, и предсказуемей, и точность равномерная. Выкидывая денормалы мы фактически обесцениваем пачку нижних порядков, что, например, для FP16 — смерти подобно. Да и, собственно, сложность работы с денормалами, на мой взгляд, сильно преувеличена (и данный топик это подтверждает: всего 3 дополнительных операции из-за денормалов). Кстати, ноль — это тоже денормал, соответственно, выкидывая их мы получаем проблему точного представления нуля.

#94
20:09, 15 янв 2022

Есть такое:
https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html
где есть обоснования и объяснения некоторым решениям IEEE754.

}:+()___ [Smile]
> Вот что стоило принять в стандарт — это требование обрабатывать денормалы в железе с той же задержкой, что и нормальные числа.
Стандарт - достаточно абстрактный документ, и о производительности вообще особо не говорит. Так что такое требование - особо некуда вставлять.
Ну и исторически - когда его принимали, такое требование было неудобным (могло замедлять основной случай).

The primary objection to Gradual Underflow arose from a fear that it would degrade the performance of the fastest arithmetics. Microcoded implementations like the i8087 and MC68881/2 had nothing to lose, but hardwired floating-point, especially if pipelined, seemed slowed by the extra steps Gradual Underflow required even if no underflows occurred. Two implementation strategies were discussed during meetings of the p754 committee. One used traps, one trap to catch results that underflowed and denormalize them to produce subnormal numbers, and another trap to catch subnormal operands and prenormalize them. The second strategy inserted two extra stages into the pipeline, one stage to prenormalize subnormal operands and another to denormalize underflowed results. Both strategies seemed to inject delays into the critical path for all floating-point operations, slowing all of them.

> А вот два нуля
> И отдельные бесконечности тоже нафиг нужны.
Насколько я помню: основная причина 0 разных знаков - именно дать обратные для бесконечностей (а то, что они на формат удобно ложатся - довесок). Дать одну бесконечность - обсуждалось (и в 387 вроде пробовали), но сошлись (вроде) на том, что проблемы и там и там, но у двух бесконечностей - меньше.
Сам Кэхен говорил, что бесконечность - mixed blessing.

> куча NaN-ов
Они не то, чтобы совсем бесполезны. Раз уж есть, им применения находят (NaN-boxing, и всякие другие; изначально, вроде, задумывалось там отладочную инфу хранить). Но формат с одним NaN'ом мог бы быть и лучше.

#95
20:23, 15 янв 2022

}:+()___ [Smile]

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

Не могу с вами согласиться. Плавающее представление имеет достаточно широкий для большинства практических целей диапазон порядков, но он по своей природе ограничен с двух сторон - со стороны нуля и бесконечности. И это всегда должно учитываться. Мы же нормально воспринимаем, когда экспонента или другая функция вызывает переполнение, и в результате получаем бесконечность. Тогда почему смущает переполнение в сторону нуля ("антипереполнение"), и обращение результата в 0? Явления в сущности симметричные.

Выкидывая денормалы мы фактически обесцениваем пачку нижних порядков, что, например, для FP16 — смерти подобно.

FP16 оставим за скобками, это отдельная тема, и там могут быть свои соображения целесообразности (а, может, и не нет). Даже для single, самого меньшего из форматов, диапазон снизу доходит примерно до 10^-38, чего на практике в большинстве случаев достаточно. Если добавить ещё несколько порядков в сторону нуля (причём ценой потери точности, которая и так небольшая!), это по сути ничего не изменит, ведь результат может получиться ещё ближе к нулю, там ещё бесконечное количество возможных порядков. Почему бы тогда не добавить порядков в сторону бесконечности для больших чисел? Им тоже может не хватить.
На самом деле, это ненужное усложнение формата, суррогат, потому что ни один здравомыслящий исследователь не будет вести расчёты на грани потери значимости, теряя при этом точность. Не хватает разрядов порядка — возьми формат с более широким полем порядка.

#96
20:33, 15 янв 2022

Aenigma
> Читал, что при обсуждении стандарта самым спорным моментом было введение
> денормализованных чисел.

Ошибкой было не введение флага который любые бы денормалы трактовал как нули. Т.е. просто сокращал бы проверку на ноль тем, что экспонента равна нулю без учёта мантиссы.
Позволило бы кому надо не терять скорости, а кому надо позарез - терпеть её потерю. Схемотехнически тоже семечки не стоящие большого обдумывания.
Вроде в SSE ввели такое.
Причём процессоры с полномасштабной поддержкой денормалов могли бы игнорировать этот флаг в будущем. А еще лучше три варианта hint: с денормалами, без денормалов и с денормалами если они хорошо поддерживаются.

#97
20:54, 15 янв 2022

=A=L=X=, вы правы, если принять факт наличия денормалов как историческую данность. Как бы то ни было, но они есть. Вот в своём формате, я разумеется, не стал их вводить, смещения порядков получились более удобные для реализации основных арифметических действий. Но это, если вручную их писать. Для современных аппаратных возможностей это пустяк.

#98
21:12, 15 янв 2022

=A=L=X=
> Ошибкой было не введение флага который любые бы денормалы трактовал как нули.
В стандарте (§8.2) есть

abruptUnderflow
When underflow is signaled because a tiny non-zero result is detected, replace the default result with a zero of the same sign or a minimum normal rounded result of the same sign, raise the underflow flag, and signal the inexact exception. When roundTiesToEven, roundTiesToAway, or the roundTowardZero attribute is applicable, the rounded result magnitude shall be zero. When the roundTowardPositive attribute is applicable, the rounded result magnitude shall be the minimum normal magnitude for positive tiny results, and zero for negative tiny results. When the roundTowardNegative attribute is applicable, the rounded result magnitude shall be the minimum normal magnitude for negative tiny results, and zero for positive tiny results. This attribute has no effect on the interpretation of subnormal operands.

Но оно рекомендуемое, а не обязательное.
В x87 флага не было, да.

#99
23:14, 15 янв 2022

FordPerfect
> Ну и исторически - когда его принимали, такое требование было неудобным (могло замедлять основной случай).
Ну вот, проблема в том, что приняли в глубокой древности и с тех пор так тянется. Я, кстати, интересовался железной реализацией поддержки денормалов, насколько помню, основная проблема была в том, что для MAD надо считать \(N_1+N_2-N_3\) для порядков и в случае денормалов должна быть поправка ±1 или даже ±2. В статье предлагалось запускать три параллельных сумматора, считающих +0, −1 и +1 для этого. Понятно, что на заре вычислительной техники такой бюджет транзисторов позволить не могли, оттуда и все проблемы.

> Насколько я помню: основная причина 0 разных знаков - именно дать обратные для бесконечностей (а то, что они на формат удобно ложатся - довесок).
На мой взгляд, это ошибка. Случаев, когда могут быть осмысленно применены бесконечности практически нет, а вот прямое нарушение логики в виде \(a=b\) одновременно с \(F(a)\neq F(b)\) — это серьезная проблема.

> NaN-boxing, и всякие другие; изначально, вроде, задумывалось там отладочную инфу хранить
Вот ни разу не встречал какой-либо дифференциации NaN-ов или их полезного использования.
Если в случае бесконечностей еще бывают варианты, то для NaN-ов я их не видел никогда.

Aenigma
> Тогда почему смущает переполнение в сторону нуля ("антипереполнение"), и обращение результата в 0?
Потому что это происходит посередине области возможных значений и выражение точности представления перестает иметь простой и понятный вид \(\varepsilon=\max\{\lambda|x|,\varepsilon_\min\}\).

> FP16 оставим за скобками, это отдельная тема
Т. е. вместо общего стандарта ты предлагаешь его разбить на несколько?

=A=L=X=
> Ошибкой было не введение флага который любые бы денормалы трактовал как нули.
Вот как раз все эти флаги округления, FP-прерываний, точности и прочий шлак дико усложняют реализацию на ровном месте. В результате та же самая функция на битово-идентичных аргументах может давать разный результат. Из-за этого же, кстати, в C++ до сих пор нет constexpr математики, вроде sin/cos, даже квадратного корня. По сравнению с денормалами, я думаю, обработка флагов округления гораздо больше транзисторного бюджета съедает (и ее нельзя на микрокод переложить, в отличие от денормалов).

#100
23:47, 15 янв 2022

}:+()___ [Smile]
> Вот ни разу не встречал какой-либо дифференциации NaN-ов или их полезного использования.
В смысле и NaN-boxing тоже не видел? Он дофига используется, в Javascript реализациях, например.
https://anniecherkaev.com/the-secret-life-of-nan

#101
0:01, 16 янв 2022

}:+()___ [Smile]
> В результате та же самая функция на битово-идентичных аргументах может давать разный результат.
That's kinda the point. Т. е. некоторые считают что такая функциональность полезна для отладки. Иногда - и сама по себе. Дискуссионно, да.

> Я, кстати, интересовался железной реализацией поддержки денормалов
Читал где-то, что в железе плавучка типично хранится с расширенной экспонентой, поэтому денормалов во внутреннем формате как бы и нету. А проблема, что округлять теперь надо не всегда по младшему разряду.

> Из-за этого же, кстати, в C++ до сих пор нет constexpr математики, вроде sin/cos, даже квадратного корня.
Уверен?
1. sin/cos всё-равно не требуются в C быть correctly-rounded, поэтому, казалось бы, направление округления не обязано влиять.
2. Стандарт IEEE754, вроде же, явно оговаривает что для compile-time вычислений нужно использовать настройки по умолчанию (и предлагает давать опцию компиляции, если нужны кастомные).

> По сравнению с денормалами, я думаю, обработка флагов округления гораздо больше транзисторного бюджета съедает (и ее нельзя на микрокод переложить, в отличие от денормалов).
Подозреваю, что да.

#102
2:24, 16 янв 2022

FordPerfect
> В смысле и NaN-boxing тоже не видел?
Ну если только так, типа компактные юнионы. В выровненные указатели тоже иногда битовые флажки подмешивают. Но я бы не назвал такое использование полезным, оно скорее свидетельствует о недостаточной информационной плотности формата.

> Читал где-то, что в железе плавучка типично хранится с расширенной экспонентой, поэтому денормалов во внутреннем формате как бы и нету.
В примитивном железе — может быть. В нормальном SIMD ALU надо прямо на месте преобразовывать, а то иначе будет как в x86 — несколько команд загрузки регистра из памяти, часть для целых, часть для плавучки, хотя по сути — одно и то же. Т. е. систему команд засрали, но что характерно, все равно не используют.

> Уверен?
Что constexpr математики нет в C++? Уверен, я за этим слежу. Даже элементарный P0533 прокатили в C++17 и C++20, когда дойдет время до настоящего P1383, вообще, непонятно.

#103
2:32, 16 янв 2022

}:+()___ [Smile]
> Что constexpr математики нет в C++?
Нет, что причина именно в округлении/исключениях.

> Даже элементарный P0533 прокатили в C++17 и C++20, когда дойдет время до настоящего P1383, вообще, непонятно.
Интересно. А у тебя есть ссылки на отчёты по обсуждениям/результаты голосований по этим вещам?

#104
2:44, 16 янв 2022

https://herbsutter.com/2021/02/22/trip-report-winter-2021-iso-c-s… ting-virtual/ :

Finally, we came close to adopting P0533 by Edward Rosten and Oliver Rosten, which is about adding constexpr to many of the functions in math.h that we share with C. This is clearly a Good Thing and therefore many voted in favor of adopting the paper. The only hesitation that stopped it from getting consensus this time were concerns that it needed more time to iron out how implementations would implement it, such as how to deal with errno in a constexpr context. This is the kind of question that often arises when we want to make improvements to entities declare in the C headers, because not only are they governed by the C standard rather than the C++ standard, but typically they are provided and controlled by the operating system vendor rather than by the C++ compiler/library writer, and those constraints always mean a bit of extra work when we want to make improvements for C++ programmers and remain compatible. As far as I know, everyone wants to see these functions made constexpr, so we expect to see this paper come to plenary again in the future. Thanks for your perseverance, Edward and Oliver!

errno это вообще не IEEE754.

Страницы: 16 7 8 911 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.