Почему денормализованные поплавки настолько медленнее, чем другие поплавки, с точки зрения архитектуры оборудования?

"Денормалы" , как известно, сильно сокращаются, 100 раз или около того, по сравнению с нормалями. Это часто вызывает проблемы неожиданные .

Мне любопытно, с точки зрения архитектуры процессора, почему денормалы должны быть , что значительно медленнее? Является ли отсутствие производительности неотъемлемой частью их неудачного представления? Или, может быть, архитекторы ЦП пренебрегают им, чтобы снизить стоимость аппаратного обеспечения при ошибочном допущении, что денормалы не имеют значения?

В первом случае, если денормалы по своей сути являются аппаратно-недружественными, существуют ли известные представления, отличные от IEEE-754 с плавающей запятой, которые также безразличны вблизи нуля, но более удобны для аппаратной реализации?

ОТВЕТЫ

Ответ 1

В большинстве систем x86 причиной медленности является то, что денормальные значения запускают FP_ASSIST, что очень дорого, поскольку оно переключается на поток микрокода (очень похоже на ошибку).

см., например, https://software.intel.com/en-us/forums/intel-performance-bottleneck-analyzer/topic/487262

Причина, по которой это так, вероятно, заключается в том, что архитекторы решили оптимизировать HW для нормальных значений, предположив, что каждое значение нормируется (что было бы более распространенным) и не хотело бы рисковать работой частых для случая редких угловых случаев. Это предположение обычно верно, поэтому вы платите только в том случае, если ошибаетесь. Эти компромиссы очень распространены в дизайне ЦП, поскольку любые инвестиции в один случай обычно добавляют накладные расходы на всю систему.

В этом случае, если вы должны были разработать систему, которая пытается оптимизировать все типы нерегулярных значений FP, вам придется либо добавить HW для обнаружения и записи состояния каждого значения после каждой операции (которая будет умножаться на количество физических регистров FP, исполнительных блоков, записей RS и т.д. - суммирование в значительном числе транзисторов и проводов. Кроме того, вам нужно будет добавить некоторый механизм для проверки значения при чтении, что замедлит работу при чтении любого значения FP (даже на обычных).

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

Ответ 2

Денормалы не обрабатываются FPU (H/W) во многих архитектурах - это оставляет реализацию в s/w

Там хорошее базовое введение https://en.wikipedia.org/wiki/Denormal_number

В разделе "Проблемы с производительностью"