Неправильно ли эта оптимизация GCC?

Ответ 1

Это пограничная оптимизация для преобразования преобразования в float приложения двойной точности log в float для приложения с одной точностью log, но можно утверждать, что она приемлема.

Предполагая, что logf правильно округлено и что двойная точность log также правильно закруглена или, по крайней мере, точно округлена, эти два вычисления будут редко отличаться. Они могут отличаться (для некоторых редких входов) из-за двойного округления (в котором "double" означает "дважды" и не ссылается на тип). Двойное округление статистически менее значимо, поскольку в промежуточном типе значимости есть дополнительные цифры по сравнению с синтаксисом конечного типа (и этот статистический аргумент является слегка мусором с математической точки зрения, но он "работает на практике" для функций, которые не были разработаны, чтобы быть контрпримерами). По дидактическим причинам люди (или Википедия) объясняют это одним или двумя дополнительными цифрами точности, но когда у вас есть 53 - 24 = 29 дополнительных двоичных цифр, можно ожидать, что это произойдет редко, как раз в 2 ²⁹.

Меня удивляет оптимизация, и я был бы обеспокоен этим, если бы сам написал код для исчерпывающего поиска проблем двойного округления с log, но учитывая, что стандарт С++ не требует какого-либо уровня точности от std::log, это можно считать "не ошибкой".

Если вместо log мы говорили об одной из основных операций (например, *), то преобразование было бы неверным, поскольку компилятор, который утверждает, что предоставляет семантику IEEE 754, когда это вводит видимые изменения. Для базовой операции точность указана косвенно IEEE 754, и спецификация не оставляет места для изменений.

Так получилось, что для основных операций не может быть видимого изменения, когда floatOP(flx,fly) заменяет (float)doubleOP((double)flx, (double)fly) (этот тезис демонстрирует это в главе 6), но могут быть видимые различия, когда типы double и long double. Эта точная ошибка была недавно исправлена ​​ в Clang by Stephen Canon.

Ответ 2

Да, эта оптимизация неверна. log и logf должны быть обязательно округлены, поэтому можно было бы

logf(4) = 0x1.62e42p+0
log(4)  = 0x1.62e42fefa39efp+0

Изменение upconvert, log и downconversion на вызов logf могут давать неверные результаты.

Ответ Паскаля Куока правильно указывает, что если logf правильно округлено, а log - не мусор, то результаты, вероятно, не будут отличаться. Однако logf на моей платформе не правильно округлен:

logf(0x1.306p-138)       = -0x1.7decc8p+6
(float)log(0x1.306p-138) = -0x1.7decc6p+6
mpfr_log(0x1.306p-138)   = -0x1.7decc6ff8a7a4a4450e9p+6

К счастью, я не могу воспроизвести эту "оптимизацию" с помощью моего gcc.

Ответ 3

Я пробовал эквивалентную программу на C:

#include <math.h>
#include <stdlib.h>
#include <stdio.h>


static double dostuff(float in)
{
  return log(in);
}

int main(int argc, char **argv)
{
  if (argc < 2)
    exit(EXIT_FAILURE);
  float in = strtof(argv[1], NULL);
  float out = dostuff(in);
  printf("%f\n", out);
  return 0;
}

И обнаружил, что gcc не использует logf даже при использовании -Ofast. Единственное, что позволяет -Ofast использовать __log_finite(). Однако изменение типа возврата dostuff() в float позволяет эту оптимизацию.

Ответ 4

Вы не должны беспокоиться о разном выходе. Если вы добавили значение float в double, а затем обратно в значение float; вы можете получить другое значение; поэтому различное значение, которое вы получаете от приведения float в двойное значение, выполнение операции журнала и последующее отбрасывание результата обратно на float не лучше, чем значение, которое вы получаете, вызывая непосредственно функцию logf.

Если вы беспокоитесь о точности операции, вам не следует использовать тип float вообще, и все ваши математические значения должны быть в два раза выше.

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