Поскольку при отсутствии кеша uop'ов декодеры вынуждены работать на весь цикл то исходная проблема кроется в предвыборке из L1I - длинные команды идущие большой группой не укладываются в темп загрузки в оные. Потому то потребно сокращение длины команд. Проблема только на Gracemont, Crestmont, в Skymont ее уже не будет (как впрочем и любых P-ядрах или на Zen'ах). Однако поскольку разрабатывается универсальная техника кодирования под эту оптимизацию - приходится использовать наихудшие возможности из всего спектра имеющихся. Он чертовски интересен ( для заинтересованных ).Тема: расширение APX. Самая интересная часть APX - расширение архитектурных РОН до 31(32) штуки.
Техника которую мы обсуждаем - способна уже сейчас дать нам аналог этих РОН, и не надо ждать пока APX воплотится в железе. И мало того что это не завтра произойдет,а в массы новое железо пойдет когда цена на него станет приемлимой. То есть через 2-4 года. И надо еще учитывать что должно произойти насыщение данным железом ( не для единичных же экземпляров кодить!) что откладывает срок еще на 2-4 года. А то о чем я пишу - это сейчас и здесь. Почувствуйте разницу.

Исправлено: mrzet, 16.01.2025 11:25

bess_temporary Неужели вы всерьёз думаете, что кто-то пытается расшифровать ваш птичий язык?

Я в этой теме спецом читаю посты mrzet , патамучта остальное вода водяная. Все слова понятны, у вас выгорание видимо, плесните кофе

Добавление от 16.01.2025 15:30:

mrzet и не надо ждать пока APX воплотится в железе

(с) святая бюрократия от Интел. Еще при рывке в х64 не было ни копеечной проблемы ортогонально добавить РОН. Бюджетов хватало. Теперь у них назрел огромный косяк с раздутым кодированием кода. Детская болезнь повзрослела и потеряла берега.

SVG4K

Вам просто не приходилось читать написанное нормальными словами

Ну и если вы так цените упомянутого товарища, то почему не подсказали ему, как устроен L3-кэш?

bess_temporary то почему не подсказали ему, как устроен L3-кэш?

L3 далеко и латентно, он в этой оптимизации не при делах. Зачем рассказывать, я же не профи. Знаю что самый бодрый L3 сейчас у Хуанга, все Х86 хуже , где это в этих статьях :
https://chipsandcheese.com/archive
https://semianalysis.com/archives/

SVG4K
Знаю что самый бодрый L3 сейчас у Хуанга, все Х86 хуж
С чего бы это?
Сомнительно дюже.
Потом почитаю, но предварительно сомневаюсь. Не те частоты работы, у х86 заметно повыше.

SVG4K

Хуанг - это не процессор и не кэш, а какой-то нерусский человек

matik
Сомнительно дюже.
Пол-года назад начинал разбираться вот тут: Архитектура кеша *) L3: кольцо vs решётка vs локальный для CCX vs Что лучше для многоядерных процессоров?, #369

VLev
Пол-года назад начинал разбираться вот тут
38нс - это намного хуже того, что в х86 процессорах. Так что предварительно правильно не верил

matik Так что предварительно правильно не верил

Все верно, Х86 лучше. В статье автор нахваливал какой быстрый L3 в районе 30нс, мол лучше всех. Ну оказывается, надо было всего то AIDA64 глянуть и увидеть 12нс в процессоре своего компа. Косяк-с.

В этих слухах написано, что у Intel NovaLake будет AVX 10.2 и APX.
07.02.25 New Leaks Point Towards Intel Arrow Lake Refresh, Nova Lake Desktop CPUs With Up To 52 Cores, Panther Lake With Up To 180 TOPs
https://wccftech.com/new-leaks-intel-arrow-lake-refr…e-up-to-180-tops/

Наконец цветок разума пробился через бетон маркетинга. Все ядра с AVX10.2 будут поддерживать 512bit инструкции, вкл. Е-cores у новых процов.
AVX10 hardware will all have 512-bit vector width support

https://www.phoronix.com/news/Intel-AVX10-Drops-256-BitThe Converged Vector ISA: Intel® Advanced Vector Extensions 10
Technical Paper March 2025 Revision 3.0
https://cdrdv2.intel.com/v1/dl/getContent/784343

Omega

Спасибо за красиво изложенную новость

Omega
Наконец цветок разума пробился через бетон маркетинга. Все ядра с AVX10.2 будут поддерживать 512bit инструкции, вкл. Е-cores у новых процов.

Omega
Маркетинг тут не причем, конечно. Просто кто серьезно облажался, когда планировал гетерогенные процессоры. В итоге пришлось отключать на Alder lake etc работающие AVX-512

А что такое "256 bit rounding" и зачем оно специально упоминается?

у AVX512 в префиксе пересекались биты указания размера регистра(256) и embedded rounding mode(фича AVX512 позволяющая указывать правила округления для отдельной инструкции, а не переключать default для всего потока в контрольном регистре
To nearest rounding mode, Toward negative infinity rounding mode, Toward positive infinity rounding mode, Toward zero rounding mode )
поэтому для 256bit это надо было обходить в компиляторе или менять формат префикса для таких инструкций в новом AVX10.2\256.

>Просто кто серьезно облажался

дык, это старая тема, предлагалось несколько вариантов как совместить с AVX512, самый очевидный quad pumping на E-cores на имеющихся EXE-модулях. Маркетологи выбрали самый простой\дешевый - отключить на P, который не надо отлаживать\сертифицировать новый микрокод для E\P.

Исправлено: Omega, 20.03.2025 16:40

Omega

Как это могли пересекаться и что такое обходить в компиляторе? Нет ли ссылки на первоисточник информации?

bess_temporary

это гуглится...

https://en.wikipedia.org/wiki/EVEX_prefix

Bit L’ for specifying 512-bit vector length, or rounding control mode when combined with L

... reuse of bits in the EVEX prefix to encode both rounding mode and register size makes it impossible to have rounding control on AVX instructions that operate on 256-bit registers.

... the different fields are EVEX.b and EVEX.L'L. According to the docs, if b is not set, then L'L is the SIMD length, so 0 = xmm and 2 = zmm. If b is set, the L'L is reinterpreted as the static rounding mode and the length is assumed to be zmm (512 bits).

>обходить в компиляторе

ранее не использовать старые инструкции с округлением с 256bit типами, а потом начать использовать новые AVX10\256 c новым префиксом? Теперь снова вернуться к "неиспользованию". Они явно считают, что это не было популярным, выбор rounding на уровне инструкций, теперь будет или через контрольный регистр, или как по-умолчанию указано для этой инструкции в микрокоде, что уже не проблема компилятора.

Исправлено: Omega, 20.03.2025 17:18

Omega

Я сейчас на смартфоне

Добавление от 20.03.2025 17:07:

Всё равно странно. Потом покопаюсь.

Добавление от 20.03.2025 20:31:

> ранее не использовать старые инструкции с округлением с 256bit типами, а потом начать использовать новые AVX10\256 c новым префиксом? Теперь снова вернуться к "неиспользованию"

Да, порнография

предлагают дополнить\заменить AVX10.2 takum-форматами для операций с матрицами.

arXiv:2503.14067v1 [cs.AR] 18 Mar 2025
Streamlining SIMD ISA Extensions with Takum
Arithmetic: A Case Study on Intel AVX10.2
https://arxiv.org/pdf/2503.14067

Beating Posits at Their Own Game: Takum Arithmetic
https://arxiv.org/pdf/2404.18603

Evaluation of Bfloat16, Posit, and Takum Arithmetics in Sparse Linear Solvers
https://arxiv.org/pdf/2412.20268

Основные характеристики Takum

Логарифмическая tapered-precision: Takum использует уникальную схему кодирования экспоненты, что позволяет более эффективно представлять числа и улучшает динамический диапазон по сравнению с Posit.
Сравнение с Posit: Исследования показывают, что Takum может превосходить Posit в некоторых аспектах, таких как стабильность и точность, особенно в задачах, связанных с разреженными линейными решателями.
Упрощение кодирования и декодирования: В отличие от Posit, длина битовой строки в Takum минимально влияет на сложность процессов кодирования и декодирования, что делает его более эффективным для аппаратной реализации.

Исправлено: Omega, 27.03.2025 02:36

Omega
Боюсь никто из производителей железа не пошевелится, пока на альтернативу IEEE-754 не будет стандарта.