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

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

Страницы: 17 8 9 10 11 Следующая »
#105
(Правка: 3:23) 3:22, 16 янв 2022

}:+()___ [Smile]
> В результате та же самая функция на битово-идентичных аргументах может давать
> разный результат.

Флоаты изначально нельзя рассматривать как битово прогнозируемые вещи, поэтому отряд не заметил потерю этого бойца. Потеря точности в них сидит изначально и на результат может повлиять просто перестановка операций компилятором. А то что x87 вообще отсебятину в 80 бит точности ввёл как дефолтный режим - отдельная песня. Можно не учитывать наличие или отсутствия такого свойства. Точнее НУЖНО было бы и без флагов округления.

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

По факту на интелях денормалы влёгкую сжирают производительность в 100 раз и наличие такого флага для схемотехники было бы раз плюнуть вообще несколькими гейтами, а выгод дало бы на мульён.
Хотя проверил - в SSE таких флагов два. Один при загрузке в АЛУ приводит денормалы к нулям - т.е. просто блокирует загрузку мантиссы если экспонента нулевая. Ну понятно, что не задача, а плюнуть и растереть парой транзисторов.
Но что значительно сложнее и что я выше забыл, что еще надо блокировать выход денормалов из АЛУ, они же могут получится и из нормалов. Тут надо подавить само исключение, что результатом будет денормал и вместо этого выдать в качестве результата ноль. Думаю на микрокод ляжет как влитое.

#106
4:06, 16 янв 2022

E.M. Schwarz, M. Schmookler, and S.D.Trong, "Hardware implementations of denormalized numbers". In: Proceedings 16th IEEE Symposium on Computer Arithmetic, June 15 2003, pp. 70-78

> изначально, вроде, задумывалось там отладочную инфу хранить
Кстати https://www.agner.org/optimize/nan_propagation.pdf .

#107
4:46, 16 янв 2022

FordPerfect
> А у тебя есть ссылки на отчёты по обсуждениям/результаты голосований по этим вещам?
Что-то есть тут.

> errno это вообще не IEEE754.
Напрямую может и нет, но само наличие альтернативных механизмов обработки ошибок помимо "return NaN" пришло оттуда. Но и помимо errno есть проблемы, типа зависимости от режима округления.

=A=L=X=
> По факту на интелях денормалы влёгкую сжирают производительность в 100 раз
Насколько я знаю, на видеокартах осилили полноскоростную поддержку денормалов, хотя там FP ALU в несколько раз больше, чем на CPU. Я думаю, что, как раз из-за всей этой мути с FP режимами из стандарта (на которую производители GPU положили болт) на CPU проблемы с нормальной поддержкой.

#108
5:43, 16 янв 2022

}:+()___ [Smile]
> Насколько я знаю, на видеокартах осилили полноскоростную поддержку денормалов,
> хотя там FP ALU в несколько раз больше

Погуглил немного: https://developer.nvidia.com/blog/cuda-pro-tip-flush-denormals-confidence/
В 2013 NVidia уже реализовала полноценную поддержку в FMA, но и только - квадратные корни и прочее продолжали тормозить.
И при этом CUDA поддерживала опцию "приводить денормалы в нули".
В общем верится, что сейчас могли полностью реализовать в железе.

Вообще не очень понятно почему такая стойкая неподдержка у интелей - если прикинуть, то у меня выходит, что надо всего лишь чтобы во внутреннем представлении в АЛУ экспонента имела больший диапазон и при загрузке в АЛУ мантисса автоматически сдвигалась так чтобы снова вернуться в нормальное представление 1.x с поправкой экспоненты на сдвинутое число бит. Ну а при выгрузке результата из АЛУ сделать соответственно сдвиг если экспонента вышла за пределы нормальности или уже вызывать исключения о переполнении. Это вроде не пахнет никаким особым криминалом, ОСОБЕННО если микрокод.

#109
5:48, 16 янв 2022

=A=L=X=
> если прикинуть, то у меня выходит, что надо всего лишь чтобы во внутреннем представлении в АЛУ экспонента имела больший диапазон и при загрузке в АЛУ мантисса автоматически сдвигалась так чтобы снова вернуться в нормальное представление 1.x с поправкой экспоненты на сдвинутое число бит.
Округление результата операций теперь не всегда по 23-му биту, а по переменному.

#110
(Правка: 6:03) 6:02, 16 янв 2022

FordPerfect
> Округление результата операций теперь не всегда по 23-му биту, а по переменному.
Учитывая, что денормалы по определению это потеря бит от 23-его и далее - такая причина лично для меня странновата. Округляй не округляй, всё равно получишь...

#111
6:45, 16 янв 2022

=A=L=X=
> при загрузке в АЛУ мантисса автоматически сдвигалась так чтобы снова вернуться в нормальное представление 1.x
Это излишне, достаточно автоматически генерировать правильный старший бит 1.x или 0.x. В отличие от сдвига, это можно сделать без дополнительной задержки (точнее, задержка будет только на этот бит, а не на все).

FordPerfect
> Округление результата операций теперь не всегда по 23-му биту, а по переменному.
FMA подразумевает поддержку вычитания, которое может приводить к старшему биту на любой позиции. Соответственно, перед округлением там всегда будет сдвиг и для денормалов надо будет подправить величину этого сдвига. Но да, логика там нетривиальная, не уверен, что можно будет это сделать без дополнительной задержки.

#112
10:36, 16 янв 2022

}:+()___ [Smile]
> Но и помимо errno есть проблемы, типа зависимости от режима округления.
Ну базовые операции над плавучкой же вполне сделали constexpr. Хотя там тоже округление и исключения/флаги.
Есть ли большая разница с sin/cos конкретно по этому параметру?

#113
10:55, 16 янв 2022

}:+()___ [Smile]
> FMA подразумевает поддержку вычитания, которое может приводить к старшему биту
> на любой позиции. Соответственно, перед округлением

поясни мне как работает FMA

#114
16:46, 16 янв 2022

FordPerfect
> Есть ли большая разница с sin/cos конкретно по этому параметру?
Казалось бы, нет, ситуация даже лучше: нет таких жестких требований к точности. Однако в предложении это тщательно рассматривают и обсуждают. Если б спросили меня, я бы сказал, что все это должно было быть constexpr начиная с 11 стандарта, но комитет, походу, на 90% состоит из "как бы чего не вышло" и принимают всякий мелкий шлак, а действительно важные и полезные вещи растягивают на десятки лет.

innuendo
> поясни мне как работает FMA
google it

#115
17:14, 16 янв 2022

}:+()___ [Smile]
> > поясни мне как работает FMA
> google it

хотелось бы услышать ваши знания

#116
21:59, 16 янв 2022

Если вместо P((x-1)/(x+1)) делать P(x)/Q(x) (в #68 похожее), т. е. деление в конце - может быть лучше latency. Для float оно осмысленно?

#117
(Правка: 4:03) 3:38, 17 янв 2022

FordPerfect, предлагаете параллельно считать числитель и знаменатель? Скорее всего, накладные расходы на пересылки данных для распараллеливания испортят производительность. А причин для ускорения не видно. Но плюсы могут быть.

Между прочим, узкое место алгоритма по точности - сложение x+1. Если мантисса нечётная, теряется один значащий бит. Это важно в конце при  умножения многочлена на (x-1)/(x+1). В одном из своих алгоритмов с двойной точностью я избавился от этого умножения, правда ценой незначительного снижения быстродействия. Хорошо было бы исправить этот момент.

Есть ещё один момент. Если деление выполнять в конце, тогда выгоднее аппроксимировать многочленом функцию x/lb вместо lb/x. Ряд для первой быстрее сходится, можно получить более точную аппроксимацию. Я так делаю в методе Паде-Чебышёва.

#118
4:14, 17 янв 2022

Aenigma
Если сначала делить, то задержка деления - ярковыражена: пока не поделили, P вычисляться не начнёт.
Если делить после - то числитель и знаменатель могут вычисляются одновременно из-за out-of-order (я не о SIMD-ификации, т. е. оба - скалярно). Задержка деления будет в конце, где она может не тормозить следующие команды.
Набросок:
https://rextester.com/QDRVX7810
Коэффициенты от балды, т. е. это чисто замер скорости.
Код, видимо, автоматически распараллелен компилятором (-O3 -mavx2 -mfma).
Чиселки прыгают, но вроде Div after быстрее стабильно (причём она на одно сложение тяжелее).

Div before: 0.458 ns/value
Div after:  0.307 ns/value
Div before: 0.391 ns/value
Div after:  0.286 ns/value
Div before: 0.320 ns/value
Div after:  0.284 ns/value
Div before: 0.354 ns/value
Div after:  0.353 ns/value
Div before: 0.408 ns/value
Div after:  0.263 ns/value
#119
(Правка: 6:54) 5:46, 17 янв 2022

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

Я могу на досуге построить аппроксимацию Паде-Чебышёва для функции f(t)=t/lb(t/3+1), |t|<=1. Для достижения одинарной точности должно хватить 4-х членов в числителе и столько же в знаменателе. Т.е. сейчас в  многочлене используется столько же. Дополнительный плюс, что это степени t, а не t^2. Ещё один плюс — возможность точно подобрать коэффициенты. Тогда и посмотрим, получится ли что-то ускорить.

Страницы: 17 8 9 10 11 Следующая »
ПрограммированиеФорумОбщее