Ответ 1
Для рукописного asm в x87 есть некоторые инструкции, которых нет в наборе инструкций SSE.
Вдобавок ко всему, это все тригонометрические вещи, такие как fsin, fcos, fatan, fatan2 и некоторые экспоненциальные/логарифмированные вещи.
С gcc -O3 -ffast-math -mfpmath=387
, GCC9 все еще будет фактически встроенным sin(x)
как инструкция fsin
, независимо от того, что использовала бы реализация в libm. (https://godbolt.org/z/Euc5gp).
MSVC вызывает __libm_sse2_sin_precise
при компиляции для 32-битного x86.
Если ваш код тратит большую часть времени на выполнение тригонометрии, вы можете увидеть небольшой выигрыш в производительности или потерю при использовании x87, в зависимости от того, является ли ваша стандартная реализация математической библиотеки с использованием SSE1/SSE2 быстрее или медленнее, чем медленный микрокод для fsin
на любом процессоре вы используете.
Производители процессоров не прикладывают больших усилий для оптимизации микрокода для инструкций x87 в новейших поколениях процессоров, потому что они обычно считаются устаревшими и используются редко. (Посмотрите на количество uop и пропускную способность для сложных команд x87 в таблицах команд Agner Fog в процессорах последних поколений: больше циклов, чем в старых процессорах). Чем новее процессор, тем больше вероятность того, что x87 будет медленнее, чем многие инструкции SSE или AVX для вычисления функций log, exp, pow или trig.
Даже когда доступен x87, не все математические библиотеки предпочитают использовать сложные инструкции, такие как fsin
, для реализации функций, таких как sin()
, или особенно exp/log, где целочисленные приемы для манипулирования битовыми шаблонами FP на основе журнала полезны.
Некоторые алгоритмы DSP используют много триггеров, но обычно извлекают большую пользу из автоматической векторизации с математическими библиотеками SIMD.
Однако для математического кода, где вы проводите большую часть своего времени, делая сложения, умножения и т.д. SSE обычно быстрее.
Также связано: Intel недооценивает границы ошибок на 1,3 квинтиллиона - наихудший случай для fsin
(катастрофическое аннулирование для входов fsin
очень близко к пи) очень плохой. Программное обеспечение может работать лучше, но только с медленными методами расширенной точности.