В общем. Справился с теми проблемами теперь вычисление dot product

выглядит как то так
sse2:
inline __m128 _dot_product_sse2(const __m128& _lhs, const __m128& _rhs)
{
__m128 mul, shuffle, sum;
mul = _mm_mul_ps(_lhs, _rhs);

shuffle = _mm_shuffle_ps(mul, mul, _MM_SHUFFLE(2, 3, 0, 1));
sum = _mm_add_ps(mul, shuffle);
shuffle = _mm_shuffle_ps(sum, sum, _MM_SHUFFLE(0, 1, 2, 3));
return _mm_add_ss(sum, shuffle);
}
sse3:
inline __m128 _dot_product_sse3(const __m128& _lhs, const __m128& _rhs)
{
__m128 mul, shuffle, sum;
mul = _mm_mul_ps(_lhs, _rhs);

shuffle = _mm_movehdup_ps(mul);
sum = _mm_add_ps(mul, shuffle);
shuffle = _mm_movehl_ps(shuffle, sum);

return _mm_add_ss(sum, shuffle);
}
sse4.1:
inline __m128 _dot_product_sse4(const __m128& _lhs, const __m128& _rhs)
{
constexpr int mask = _Size == 2ull ? 0x31 : (_Size == 3ull ? 0x71 : 0xF1);
return _mm_dp_ps(_lhs, _rhs, mask);
}

Получилось, что sse3 медленнее чем sse2 в среднем на 0.15ns, а sse4.1 медленнее чем sse2 в 2.5 раза
Замеры на этот раз делал с google benchmark

нативный dot на моей памяти никогда быстрым не был, как и horizontal add

4.1 допустим бранчи имеет.

Бранчи?

Тернарный оператор.

Branch

Тип из за маски?

Да. Весь пайплайн к чертям.

И какой результат бенча? А компилятор сам не векторизует если добавить -О3 —ffast-math

Я собираю на msvc 2019 со стандартными настройками. Оптимизация -O2

В итоге то удалось лучше написать чем a1*b1+a2*b2+a3*b3?

У тебя неверные замеры. И фундаментально и даже на уровне базовых метрик(типа использование наносекунд), да и гугл-бенчмарк днище как и практически все подобные пускалки. _mm_movehdup_ps и _mm_movehl_ps - это не инструкции, а интел-баланда зависящая от реализации. Особенно если ты используешь какой-нибудь msvc в котором реализация чего угодно позорище. Разница в каких-то 0.15ns - это явно мусор. Это более любой существующей частоты. Даже если ты замерял трупут, то там не может быть такого шага.

Не инструкции? movshdup movhlps Первый SSE)

по поводу dpps - по спекам там всё нормально и сливать оно не должно. Проблема в реализации и методиках измерения. Хотя подобная проблема есть практически везде. Чем дальше задержки на иструкциях от единицы - тем больше нужно умения/понимания для их использования

haddps (SSE3) пробовал ли? Просто интересно посмотреть по перфе

0.15ns это разница с частичной constexpr реализацией если что

Значит инструкции. Смотрел на реализацию. А судя по тому что я их в глаза не видел и тому, что реализация в них не форвардит - они никому ненужны. Хотя да, судя по ттх это очередной мусор уровня микрода от интела.

Не в этом дело. Слишком сомнительно выглядит разница. Летенси не может быть не кратна тактам, если ты её замеряешь. Если ты замеряешь трупут - он где-то в районе кратности ширины фронта.

по поводу того почему у тебя сливает dpps. У этой инструкции очень большие задержки, а значит тебе нужен высокий уровень параллелизма в твоём коде. Которого у тебя нет, очевидно. Да и мало у кого есть. Это одна из причин почему никогда ненужно использовать любые sse. Там мало регистров и убогие двуоперандные инструкции, которые делают ещё меньше регистров.

У SSE мало регистров?

Ну по пикселям я итерируюсь с помощью std::for_each(std::execution::par... может быть это тоже влияет

Я думаю, Роман всё-таки про instruction level parallelism

Всё влияет. Если ты обмазываешься подобным лучше последуй совету людей и используй готовую либу. Тебе никак не поможет это разобраться в теме. Ты будешь ловить сайд-эффекты и считать их за свойства реальности и только запутаешь себе голову

Не согласен с озвученным советом. Я б предложил обложиться vtune'ом и научиться измерять нормально все озвученные спецэффекты. Инструментарий есть.

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

он сам по себе слоупочный