Почему SSE скалярный sqrt(x) медленнее, чем rsqrt (x) * x?

Я профилировал некоторые из наших основных математических операций на Intel Core Duo, и, глядя на различные подходы к квадратному корню, я заметил что-то странное: используя скалярные операции SSE, быстрее взять обратный квадратный корень и умножить его, чтобы получить sqrt, чем использовать собственный код операции sqrt!

я тестирую его с петлей что-то вроде:

inline float TestSqrtFunction( float in );

void TestFunc()
{
  #define ARRAYSIZE 4096
  #define NUMITERS 16386
  float flIn[ ARRAYSIZE ]; // filled with random numbers ( 0 .. 2^22 )
  float flOut [ ARRAYSIZE ]; // filled with 0 to force fetch into L1 cache

  cyclecounter.Start();
  for ( int i = 0 ; i < NUMITERS ; ++i )
    for ( int j = 0 ; j < ARRAYSIZE ; ++j )
    {
       flOut[j] = TestSqrtFunction( flIn[j] );
       // unrolling this loop makes no difference -- I tested it.
    }
  cyclecounter.Stop();
  printf( "%d loops over %d floats took %.3f milliseconds",
          NUMITERS, ARRAYSIZE, cyclecounter.Milliseconds() );
}

Я пробовал это с несколькими различными телами для TestSqrtFunction, и у меня есть несколько таймингов это действительно царапает мне голову. Хуже всего было использовать собственную функцию sqrt() и позволить "умному" компилятору "оптимизировать". В 24нс/поплавок, с помощью операций с плавающей запятой x87, так это было трогательно плохо:

inline float TestSqrtFunction( float in )
{  return sqrt(in); }

следующее, что я попытался использовать встроенную функцию, чтобы заставить компилятор использовать скалярный код SSE sqrt:

inline void SSESqrt( float * restrict pOut, float * restrict pIn )
{
   _mm_store_ss( pOut, _mm_sqrt_ss( _mm_load_ss( pIn ) ) );
   // compiles to movss, sqrtss, movss
}

Это было лучше, на 11,9 НС / поплавок. Я тоже пробовал дурацкий метод приближения Ньютона-Рафсона Кармака, который побежал даже лучше, чем аппаратное обеспечение, на 4,3 НС / поплавок, хотя и с ошибкой 1 в 2¹⁰ (что слишком много для моих целей).

doozy был, когда я попробовал SSE op для взаимные квадратный корень, а затем используется умножение, чтобы получить квадратный корень ( x * 1/√x = √x ). Несмотря на то, что это требует двух зависимых операций, это было самое быстрое решение на сегодняшний день, на 1.24 НС/float и с точностью до 2^-14:

inline void SSESqrt_Recip_Times_X( float * restrict pOut, float * restrict pIn )
{
   __m128 in = _mm_load_ss( pIn );
   _mm_store_ss( pOut, _mm_mul_ss( in, _mm_rsqrt_ss( in ) ) );
   // compiles to movss, movaps, rsqrtss, mulss, movss
}

мой вопрос в принципе что дает? почему SSE встроенный в аппаратный квадратный корень код операции медленнее чем синтезировать его из двух других математических операций?

Я уверен, что это действительно стоимость самой ОП, потому что я проверил:

• все данные помещаются в кэш, и доступы являются последовательными
• функции встроены
• разворачивание цикла не имеет никакого значения
• флаги компилятора установите полную оптимизацию (и сборка хорошая, я проверил)

(edit: stephentyrone правильно указывает, что операции на длинные строки чисел следует использовать векторизацию Симд упакованные ОПС, как rsqrtps - но структура данных массива здесь предназначена только для тестирования: то, что я действительно пытаюсь измерить, это скаляр производительность для использования в коде, который не может быть векторизован.)