Если у меня есть 2 денормализованных числа с плавающей запятой с разными битовыми шаблонами и я сравниваю их на равенство, может ли на результат повлиять флаг Denormals-Are-Zero, флаг Flush-to-Zero или другие флаги на часто используемых процессорах?
Или эти флаги влияют только на вычисления, а не на проверку равенства?
DAZ (денормалы равны нулю) влияет на чтение ввода, поэтому DAZ влияет на сравнение. Все денормалы буквально трактуются как -0.0 или +0.0 в зависимости от их знака.
FTZ (Flush To Zero) влияет только на запись вывода, поэтому FTZ не влияет на сравнение. Сравнения не производят вывод FP, так что сбрасывать нечего.
(DAZ и FTZ — это флаги в регистре управления/статуса SSE MXCSR. Для x87 эквивалента нет.)
Почему оба флага существуют отдельно, а не один флаг, управляющий обеими вещами? Я не знаю, но вам определенно нужны оба эффекта.
Вы можете считывать данные FP из файла или из сети, поэтому вы можете напрямую получать денормализованные входные данные, а не результат ваших вычислений. Так что вам нужен DAZ для этого.
Создание правильного денормального вывода (например, путем вычитания соседних нормальных чисел или умножения двух небольших нормальных чисел) потенциально медленно, поэтому вам нужно, чтобы FTZ позволял ЦП просто снижать значение до +-0.0 вместо того, чтобы использовать помощь микрокода, чтобы получить правильное значение.
Или у вас может быть один поток, работающий с быстрой математикой (FTZ+DAZ), в то время как другой поток работает с точной математикой для некоторых вычислений, которые требуют этого. Если быстрый математический поток считывает данные, созданные точным потоком, эти числа могут быть денормализованными.
Я не уверен, какой вариант использования будет для установки DAZ, но не FTZ, или наоборот. Это, безусловно, потребует чтения данных, которые вы не создавали сами, или записи данных для других читателей, кроме вас самих, в противном случае достаточно просто FTZ, чтобы избежать каких-либо замедлений.
(Одного только DAZ недостаточно: создание денормализованного вывода из обычных входных данных все еще происходит медленно, даже если следующая операция рассматривает его как 0.)
nextafter/nextafterf< /a>, который должен сравнивать входные данные, чтобы увидеть, в каком направлении двигаться. Я даже спросил Реализация std::nextafter: Должен ли на это влиять режим denormals-are-zero? Если да, то как?, но так и не вернулся к этому.
- person Peter Cordes; 05.01.2019
nextafterf() с DAZ/FTZ. У меня два мнения: Либо nextafterf() доверяет пользователю и безоговорочно дает следующее число с плавающей запятой, денормализованное или нет, и пользователь должен иметь в виду, что другие флаги могут сделать f-nextafterf(f, ...) == 0; Или nextafterf() не доверяет пользователю и возвращает следующее нормальное число или 0. В этом случае будет учитываться DAZ и игнорироваться FTZ. Соблюдение ЗСТ или того и другого приведет к ситуациям, когда f != next(prev(f)), что я считаю неприемлемым.
- person Iwillnotexist Idonotexist; 05.01.2019
FTZилиDAZ, только дляSSE. - person EOF schedule 05.01.2019FTZне имеет никакого эффекта, так как он сбрасывает до нуля денормализованные результаты с плавающей запятой, а сравнение на равенство дает не результат с плавающей запятой, а логический.DAZимеет эффект, так как он говорит процессору рассматривать все денормалы как одно и то же, а именно 0. - person Iwillnotexist Idonotexist schedule 05.01.2019