Зависит ли время вычисления арифметики от IEEE от значения?

Question

Я использую строгую арифметику IEEE с плавающей запятой в решателе CFD. Мой алгоритм является явным и детерминированным (он будет выполнять одинаковое количество вычислений на каждом временном шаге). Тем не менее, я наблюдаю, что в периоды, когда решение... сложно (множество вещей происходит по всей сетке), решатель "застревает" и идет медленнее.

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

Может ли IEEE-строгое выполнение с плавающей запятой зависеть от значения?

Answer 1

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

Set R1 if first operand is NaN or second operand is +/- 1.0
Set R2 if second operand is NaN or first operand is +/- 1.0
Set Z if either operand is +/- 0.0
Set N if either operand is NaN
If (R1 or R2 or Z)
  Set the body of the result, excluding sign, to the (first-op & R1) | (second-op & R2)
  Set the sign of the result to (first-op & (R1 | !N)) ^ (second-op & (R2 | !N))
  Skip the rest of the multiplication

Добавление вышеупомянутой логики приведет к умножению с плавающей запятой на +/- 1,0 или +/- 0,0 к выполнению в шестой части времени, необходимого для умножения, не связанного с такими константами. Существует много сценариев, в которых код принимает произвольные коэффициенты масштабирования, но чаще всего используется с коэффициентами масштабирования, равными нулю или единице; например, некоторые графические приложения могут разрешать произвольное масштабирование, вращение и сдвиг, но чаще всего используются с коэффициентом масштабирования один, без поворота и без сдвига. Ускорение умножения на ноль и единицу, несмотря на то, что требуется меньше аппаратного обеспечения, чем потребовалось бы для улучшения большинства умножений на цикл, во многих сценариях может обеспечить более полезное повышение производительности.