Показатель SSE векторной оболочки по сравнению с голым __m128

Ответ 1

Как выяснилось, проблема не в определении пользователя struct Vec4. Он глубоко связан с соглашениями о вызовах x86.

Стандартное соглашение об использовании x86 по умолчанию в Visual С++ - это __cdecl, которое

Вставляет параметры в стек, в обратном порядке (справа налево)

Теперь это проблема, так как Vec4 следует хранить и передавать в регистре XMM. Но посмотрим, что на самом деле происходит.

1-й случай

В первом случае Vec4 является псевдонимом простого типа __m128.

using Vec4 = __m128;
/* ... */
Vec4 TestEQ(EQSTATE* es, Vec4 &sample) { ... }

Сгенерированный заголовок функции TestEQ в сборке -

[email protected]@[email protected]@[email protected]@[email protected]@Z PROC      ; TestEQ, COMDAT
; _es$ = ecx
; _sample$ = edx
...

Ницца.

Второй случай

Во втором случае Vec4 не является псевдонимом __m128, теперь он является определяемым пользователем.

Здесь я исследую компиляцию для платформы x86 и x64.

x86 (32-разрядная компиляция)

Так как __cdecl (который является стандартным вызовом для вызова в x86), он не позволяет передавать выровненные значения в функции (которые испускают Error C2719: 'sample': formal parameter with requested alignment of 16 won't be aligned), мы передаем его ссылкой const.

struct Vec4{ __m128 simd; /* ... */ };
/* ... */
Vec4 TestEQ(EQSTATE* es, const Vec4 &sample) { ... }

который генерирует заголовок функции для TestEQ как

[email protected]@[email protected]@[email protected]@[email protected]@Z PROC        ; TestEQ, COMDAT
; ___$ReturnUdt$ = ecx
; _es$ = edx
    push    ebx
    mov ebx, esp
    sub esp, 8
    and esp, -8                 ; fffffff8H
    add esp, 4
    push    ebp
    mov ebp, DWORD PTR [ebx+4]
    mov eax, DWORD PTR _sample$[ebx]
    ...

Это не так просто, как в первом случае. Аргументы переносятся в стек. Есть несколько дополнительных инструкций mov между первыми инструкциями SSE, которые здесь не перечислены. Этих инструкций в целом достаточно, чтобы немного поразить производительность.

x64 (64-разрядная компиляция)

Windows в x64 использует другое соглашение о вызове как часть бинарного интерфейса приложения (64).

Это соглашение пытается сохранить данные в регистрах, если это возможно, таким образом, что данные с плавающей запятой сохраняются в регистрах XMM.

От MSDN Обзор x64 соглашений о вызовах:

Бинарный интерфейс приложения x64 (ABI) - это 4-х быстрый быстрый вызов вызывающего соглашения, с поддержкой стека для этих регистров. Eсть строгое взаимно однозначное соответствие между аргументами в функции и регистры для этих аргументов. Любой аргумент, который не подходит для 8 байты, или не 1, 2, 4 или 8 байтов, должны передаваться по ссылке. (...) Все операции с плавающей запятой выполняются с использованием 16 регистров XMM. Аргументы передаются в регистры RCX, RDX, R8 и R9. Если аргументы float/double, они передаются в XMM0L, XMM1L, XMM2L и XMM3L. 16 аргументы байта передаются по ссылке.

Из Страница Википедии для соглашений о вызовах x86-64

В Windows используется соглашение о вызове Microsoft x64 и pre-boot UEFI (для длинного режима на x86-64). Он использует регистры RCX, RDX, R8, R9 для первых четырех целых или указательных аргументов (в этом порядок), а XMM0, XMM1, XMM2, XMM3 используются для с плавающей запятой аргументы. Дополнительные аргументы помещаются в стек (справа на оставил). Возвращаемые значения Integer (похожие на x86) возвращаются в RAX, если 64 бит или меньше. Возвращаемые значения с плавающей точкой возвращаются в XMM0.

Итак, второй случай в режиме x64 генерирует заголовок функции для TestEQ как

[email protected]@[email protected]@[email protected]@[email protected]@Z PROC        ; TestEQ, COMDAT
; _es$ = ecx
; _sample$ = edx
...

Это точно так же, как в первом случае!

Решение

В режиме x86 представленное поведение должно быть четко зафиксировано.

Наиболее простым решением является функция inline. Хотя это всего лишь подсказка, и компилятор может полностью игнорировать, вы можете сказать компилятору всегда встроить функцию. Однако иногда это нежелательно из-за размера функции или по любой другой причине.

К счастью, Microsoft представила соглашение __vectorcall в Visual Studio 2013 и выше (доступно в режиме x86 и x64). Это очень похоже на стандартное соглашение об использовании Windows x64 по умолчанию, но с более доступными регистрами.

Перепишите второй случай с __vectorcall:

Vec4 __vectorcall TestEQ(EQSTATE* es, const Vec4 &sample) { ... }

Теперь сгенерированный заголовок функции сборки для TestEQ равен

[email protected]@[email protected]@[email protected]@[email protected]@Z PROC        ; TestEQ, COMDAT
; _es$ = ecx
; _sample$ = edx
...

который, наконец, тот же, что и первый случай, и второй случай в x64.

Как указал Питер Кордес, чтобы в полной мере воспользоваться __vectorcall, аргумент Vec4 должен быть передан по значению вместо постоянной ссылки. Для этого переданный тип должен удовлетворять некоторым требованиям, например, он должен быть тривиально копируемым конструктивным (без пользовательских конструкторов копирования) и не должен содержать никакого объединения. Подробнее в комментариях ниже и здесь.

Заключительные слова

Похоже, что MSVC под капотом автоматически применяет соглашение __vectorcall как оптимизацию, когда обнаруживает аргумент __m128. В противном случае используется условное соглашение по умолчанию __cdecl (вы можете изменить это поведение по параметрам компилятора).

Люди сказали мне в комментариях, что они не видели большой разницы между GCC и Clang, сгенерированной сборкой из двух случаев. Это связано с тем, что эти компиляторы с флагом оптимизации -O2 просто встраивают функцию TestEQ в тело тестового цикла (см.). Также возможно, что они будут более умными, чем MSVC, и они будут лучше оптимизировать вызов функции.