AMD Ryzen 7 9700X показує кращу продуктивність у Linux — до 13% швидше в іграх відносно Windows

[Scoffer]

This engine now includes eight-wide instruction dispatch and retire capability each cycle, an increase from the six of Zen 4.

В оцьому виділеному тобою жирним, на що я зауважив, що на компілятори це не впливає, їм начхати.

[vmsolver]

мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.

Это всё не про ОоО механизм

[vdemeshko]

This engine now includes eight-wide instruction dispatch and retire capability each cycle, an increase from the six of Zen 4.

В оцьому виділеному тобою жирним, на що я зауважив, що на компілятори це не впливає, їм начхати.

это не мои утвреждения вообще я попрошу привести мои давайте вернемся к мои утвреждениям

Отправлено спустя 5 минут 39 секунд:

мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.

Это всё не про ОоО механизм

а фронтенд каким то волшебным образом наполняет OoO pipepline очередь без кеша микроопераций, кеша L1I ? пришел вечер акуительных историй у костра я так понимаю а то тут есть одни придурки из Apple сделавшие 192 KB of L1I в M1 зачем же оно надо для быстрого OoO процессора я не удивлюсь если в Zen 6 он станет 64KB или больше


PS
я просто осталю это здесь как "памятник не влияния на OoO" и тому куда в приципе закладывают будущее изменения AMD (imho) - сори обрезал на скриншоте буфер очереди микроопераций в OoO pipepline Zen 5 где есть ее увеличение
https://www.anandtech.com/show/16226/ap ... eep-dive/2
Вот от сюда слайд если что.. там же и анализ изменений архитектуры и кто влияет на скорость OoO отлично видно а остальные акуительные истории это уже без меня

[vmsolver]

такс.. где я утверждал обратное

Всё началось с того, что ты написал:

Подозреваю что дело в поддержке компиляторами в линукс новых архитектурных изменений в Ryzen 5 в том числе

А потом выделил вот эту фразу:

This engine now includes eight-wide instruction dispatch and retire capability each cycle, an increase from the six of Zen 4

И дополнил этим:

Это вообще существенное изменение за 10ки лет архитектуры х86 если верно помню с OoO исполнением инструкций

И окончательно добил уже этим:

То есть в линухе компилятор может генерировать оптимизации под расширенное окно выполнения команд для этой архитектуры

Таким образом всё вместе это означает, что ты считаешь, что в компиляторе что-то подстраивается под ширину запуска/отставки, а также ширину окна ОоО.

>> Это всё не про ОоО механизм
а фронтенд каким то волшебным образом наполняет OoO pipepline очередь

Так наполняет, а не является им. Элементарные же вещи путаешь. Прекращай.

[vdemeshko]

Так наполняет, а не является им. Элементарные же вещи путаешь. Прекращай.

тебе начинает что то доходить да да.. именно.. что бы обеспечить его работу нужно наполнить.. 1) наполнить из L1I 2) декодировать в микрооперации(про это чуть ниже).. и да примера моих утверждений что in order фронтед является OoO pipeline я так понимаю не будет?

Таким образом всё вместе это означает, что ты считаешь, что в компиляторе что-то подстраивается под ширину

-march=znver5 и тд
все верно... в предыдущем патче gcc Zen 4 table (x86-tune-costs.h) вижу как минимум изменения по размеру кеша в сравнении Zen 3 vs Zen 4... именно эта команда включает оптимизации для архитектуры конкретно c этими изменениями (-march=znver4 в данном случае ) и в ней есть, как я вижу в прошлом патче изменение для размера кеша(в новом патче судя по каментам в гитхабе - это кописпаста для Zen 4). Выше у нас вроде нет разногласий что OoO нужно наполнить.. Ты вырываешь слова из контекста треда когда я указывал что компилятору указывают ключи оптимизации и есть конкретные ограничения которые влияют косвенно на скорость наполнения OoO pipepline очереди. Утверждение что косвенно влияем путем указания ограничений в компиляторе на эффективность загрузки OoO pipeline не вступает в противоречия. Определение "что то подстраиваемого под ширину" вырисовалось в размере кеша к примеру при активации ключа оптимизации.. Код же читать надо что там указывают в изменениях для этих ключей что бы была конкретика. Я привел пример с кешем из предидущего патча.

Это вообще существенное изменение за 10ки лет архитектуры х86 если верно помню с OoO исполнением инструкций

Все верно - продолжим начатое.. еще раньше было вообще 4-wide если верно помню.. 8-wide у Apple M1 появилось что в купе с гигантским L1I 192KB кешем сделало самым быстрым OoO процессором на рынке. Казалось бы зачем нужен 192KB L1I + 8-wide decoder... think about it (c) meme

Отправлено спустя 34 минуты 54 секунды:
тут еще интересное видео появилось с похожими мыслями (ну они совпадают с моими по крайне мере когда посмотрел тесты на Phoronix и игровых ресурсах)

ну собственно о чем я и утверждал - что софт еще не готов (компиляторы только часть его впрочем как и еще не готовы все оптимизации в нем в полном обьеме, микрокод AGESA и тд + патчи для Windows. Там проблема с шедьюлером давняя была если верном помню с в Win 11 ). Linux мир тут на шажочек опережает - потому там и выше по тестам прирост, но очевидно? что главная цель это рынок серверов так как там высокая маржинальность и туда пока направлены ресурсы скорее всего в плане поддержки патчами со стороны АМД. Мы с десктопами уже прицепом а ну вот еще

[man1242]

vdemeshko
Это тот редкий (:)) случай, когда Scoffer прав, компилятор действительно никак не влияет на ОоО механизм в процессоре, никак не учитывает его параметры и так далее. Сам подумай, если бы компилятор что-то подстраивал под ОоО окно одного процессора, то что должно быть у процессора с другим ОоО окном, медленней работать? А не должно быть такого, поэтому нет, переупорядочивание это сугубо внутренняя функция процессора, у каждого она реализована по-разному и это дело только процессора, компилятор абстрагирован от этого механизма и на него не влияет и ничего не подстраивает.

По сути, компилятор не знает о ОоО механизме, ему не важно, он просто формирует оптимизированную последовательность из ограниченного набора инструкций, а исполнением занимается железо, оно само разбирается как и что ему делать, причем в реальном времени, о чём компилятор не знает и в принципе знать не может (доказано Итаниумом, где компилятор пытался оптимизировать код так, чтобы все конвейеры были заняты - это приблизительная аналогия контроля/замены компилятором ОоО окна, и получалось у него откровенно плохо, настолько плохо, что многие даже не знают про Итаниум).

такс.. где я утверждал обратное цитату... мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.. собственно что я вижу в патче для Zen 4 того же в сравнении с Zen 3.. то естьэто может помочь эффективней загрузить пайплайн OoO - вроде только эти утверждения были с моей стороны.. только косвенное влияние - где про прямое влияние на оптимизацию OoO со стороны компилятора я не могу понять нашли в моих постах. Точнее даже не так.. компилятор должен узнать о том, что есть какие то изменения как добавления инструкций так и их стоимость, впрочем как и размеры кеша и тд (ссылке выше на патч.. для Zen5 указано что это копипаста Zen 4 на данный момент в коде на гитхабе) для конкретной итерации архитектуры конкретного производителя. Так есть и у Intel так и других архитектур(не x86).

полотна не читал, но когда увидел решение проблемы с потеряным фпс в виндовс встал вопрос это сделано умышленно еще начиная с райзен 7000 серии или нет ?)

[Inqizitor2022]

Можно вкратце кто виноват? Моё мнение - индусы облажались снова и по хорошему, нужно винду оптимизировать до вида, когда фпс будет одинаковый

[AndP]

Перенес в нужную тему

[vdemeshko]

Можно вкратце кто виноват?

Покупатели те которые early adopters

[AlexKuzovkov]

А от і тест с на 24Н2 вінді.

спойлер

[NST1983]

Срані індуси https://prnt.sc/il-L94zIkgE2

[AlexKuzovkov]

Срані індуси

А що тепер Інтел буде робити? Там темає апу.