Почему инструкции SSE сохраняют верхние 128-битные регистры YMM?

Кажется, что повторяющаяся проблема, что многие процессоры Intel (вплоть до Skylake, если я ошибаюсь) демонстрируют низкую производительность при смешивании инструкций AVX-256 с SSE инструкции.

Согласно документации Intel, это вызвано инструкциями SSE, которые определены для сохранения верхних 128 бит регистров YMM, поэтому в порядке чтобы иметь возможность экономить электроэнергию, не используя верхние 128 бит данных datapaths, процессор сохраняет эти биты при выполнении кода SSE и перезагружает их при вводе кода AVX, магазины и нагрузки стоят дорого.

Однако я не могу найти очевидной причины или объяснения, почему инструкции SSE необходимы для сохранения этих верхних 128 бит. Соответствующие 128-битные инструкции VEX (использование которых позволяет избежать снижения производительности) работают, всегда очищая верхние 128 бит регистров YMM, а не сохраняя их. Мне кажется, что когда Intel определила архитектуру AVX, в том числе расширение регистров XMM в регистры YMM, они могли бы просто определить, что инструкции SSE также очистят верхние 128 бит. Очевидно, что, поскольку регистры YMM были новыми, не могло быть никакого устаревшего кода, который зависел бы от инструкций SSE, сохраняющих эти биты, и также мне кажется, что Intel могла бы легко увидеть это.

Итак, в чем причина, почему Intel определила инструкции SSE для сохранения верхних 128 бит регистров YMM? Это когда-нибудь полезно?

Ответы

Ответ 1

Чтобы переместить внешние ресурсы на сайт, я извлек соответствующие абзацы из ссылки Майкла в комментариях.

Все кредиты идут к нему.
Ссылка указывает на очень похожий вопрос, заданный Agner Fog на форуме Intel.

[Туман в ответ на ответ Intel] Если я правильно понял, вы решили, что необходимо иметь две версии всех 128-битных инструкций, чтобы избежать уничтожая верхнюю часть регистров YMM в случае, если прерывание вызывает драйвер устройства с использованием устаревших инструкций XMM.

Intel обеспокоена тем, что, дав устаревшие инструкции SSE обнулить верхнюю часть регистров XMM, ISR теперь внезапно влияют на новые регистры YMM.
Без поддержки для сохранения нового контекста YMM это сделало бы невозможным использование AVX при любых обстоятельства.

Однако Fog не был полностью удовлетворен и указал, что просто перекомпилировав драйвер с помощью AVX-компилятора (так что VEX были использованы) приведут к такому же результату.

Intel ответила, что их целью было избежать принудительного использования существующего программного обеспечения переписаны.

Мы не можем заставить отрасль переписывать/исправить все существующие драйверы (например, использовать XSAVE), и не могли гарантировать, что они сделали бы это успешно. Рассмотрим, например, боль, которую отрасль все еще переживает при переходе от 32 до 64-битных операционных систем! Отклики, которые мы получаем от поставщиков ОС, также препятствовали добавлению накладных расходов на обслуживание ISR для добавления накладных расходов на управление на каждом прерывании. Мы не хотели накладывать ни одну из этих затрат на части отрасли, которые даже не используют обычно широкие векторы.

Имея две версии инструкций, поддержка AVX в драйверах может быть достигнута, как и для FPU/SSE:

Приведенный пример аналогичен существующему сценарию, в котором поставщик драйверов ring-0 (ISR) пытается использовать состояние с плавающей запятой или случайно связывает его в некоторой библиотеке в операционных системах, которые автоматически не управляют этим контекстом в Ring- 0. Это известный источник ошибок, и я могу предложить только следующее:

  • В этих ОС разработчикам драйверов не рекомендуется использовать с плавающей точкой или AVX

  • Разработчикам драйверов следует поощрять отключать аппаратные функции во время проверки драйверов (то есть состояние AVX может быть отключено драйверами в Ring-0 до XSETBV()

Ответ 2

Предыстория: решение было принято раньше, чтобы заставить KeSaveFloatingPointState ничего не делать в Windows x64 и разрешить использование регистров XMM без дополнительных вызовов для восстановления/восстановления даже в драйверах. Очевидно, что эти драйверы не будут знать о AVX или YMM-регистрах.