В оцьому виділеному тобою жирним, на що я зауважив, що на компілятори це не впливає, їм начхати.vdemeshko: ↑ 15.08.2024 11:29This engine now includes eight-wide instruction dispatch and retire capability each cycle, an increase from the six of Zen 4.
Останні статті і огляди
Новини
AMD Ryzen 7 9700X показує кращу продуктивність у Linux — до 13% швидше в іграх відносно Windows
-
Scoffer
Member
-
vmsolver
Member
Это всё не про ОоО механизмvdemeshko: ↑ 15.08.2024 13:53мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.
-
vdemeshko
Member
- Звідки: Киев
это не мои утвреждения вообще я попрошу привести мои давайте вернемся к мои утвреждениямScoffer: ↑ 15.08.2024 13:55В оцьому виділеному тобою жирним, на що я зауважив, що на компілятори це не впливає, їм начхати.vdemeshko: ↑ 15.08.2024 11:29This 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 или большеvmsolver: ↑ 15.08.2024 14:02Это всё не про ОоО механизмvdemeshko: ↑ 15.08.2024 13:53мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.
PS
я просто осталю это здесь как "памятник не влияния на OoO" и тому куда в приципе закладывают будущее изменения AMD (imho) - сори обрезал на скриншоте буфер очереди микроопераций в OoO pipepline Zen 5 где есть ее увеличение
https://www.anandtech.com/show/16226/ap ... eep-dive/2
Вот от сюда слайд если что.. там же и анализ изменений архитектуры и кто влияет на скорость OoO отлично видно а остальные акуительные истории это уже без меня
-
vmsolver
Member
Всё началось с того, что ты написал:vdemeshko: ↑ 15.08.2024 13:53такс.. где я утверждал обратное
А потом выделил вот эту фразу:Подозреваю что дело в поддержке компиляторами в линукс новых архитектурных изменений в Ryzen 5 в том числе
И дополнил этим:vdemeshko: ↑ 15.08.2024 11:29This engine now includes eight-wide instruction dispatch and retire capability each cycle, an increase from the six of Zen 4
И окончательно добил уже этим:Это вообще существенное изменение за 10ки лет архитектуры х86 если верно помню с OoO исполнением инструкций
Таким образом всё вместе это означает, что ты считаешь, что в компиляторе что-то подстраивается под ширину запуска/отставки, а также ширину окна ОоО.То есть в линухе компилятор может генерировать оптимизации под расширенное окно выполнения команд для этой архитектуры
Так наполняет, а не является им. Элементарные же вещи путаешь. Прекращай.vdemeshko: ↑ 15.08.2024 14:45 >> Это всё не про ОоО механизм
а фронтенд каким то волшебным образом наполняет OoO pipepline очередь
-
vdemeshko
Member
- Звідки: Киев
тебе начинает что то доходить да да.. именно.. что бы обеспечить его работу нужно наполнить.. 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 не вступает в противоречия. Определение "что то подстраиваемого под ширину" вырисовалось в размере кеша к примеру при активации ключа оптимизации.. Код же читать надо что там указывают в изменениях для этих ключей что бы была конкретика. Я привел пример с кешем из предидущего патча.
Все верно - продолжим начатое.. еще раньше было вообще 4-wide если верно помню.. 8-wide у Apple M1 появилось что в купе с гигантским L1I 192KB кешем сделало самым быстрым OoO процессором на рынке. Казалось бы зачем нужен 192KB L1I + 8-wide decoder... think about it (c) memeЭто вообще существенное изменение за 10ки лет архитектуры х86 если верно помню с OoO исполнением инструкций
Отправлено спустя 34 минуты 54 секунды:
тут еще интересное видео появилось с похожими мыслями (ну они совпадают с моими по крайне мере когда посмотрел тесты на Phoronix и игровых ресурсах)
ну собственно о чем я и утверждал - что софт еще не готов (компиляторы только часть его впрочем как и еще не готовы все оптимизации в нем в полном обьеме, микрокод AGESA и тд + патчи для Windows. Там проблема с шедьюлером давняя была если верном помню с в Win 11 ). Linux мир тут на шажочек опережает - потому там и выше по тестам прирост, но очевидно? что главная цель это рынок серверов так как там высокая маржинальность и туда пока направлены ресурсы скорее всего в плане поддержки патчами со стороны АМД. Мы с десктопами уже прицепом а ну вот еще
-
man1242
Member
полотна не читал, но когда увидел решение проблемы с потеряным фпс в виндовс встал вопрос это сделано умышленно еще начиная с райзен 7000 серии или нет ?)vdemeshko: ↑ 15.08.2024 13:53такс.. где я утверждал обратное цитату... мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.. собственно что я вижу в патче для Zen 4 того же в сравнении с Zen 3.. то естьэто может помочь эффективней загрузить пайплайн OoO - вроде только эти утверждения были с моей стороны.. только косвенное влияние - где про прямое влияние на оптимизацию OoO со стороны компилятора я не могу понять нашли в моих постах. Точнее даже не так.. компилятор должен узнать о том, что есть какие то изменения как добавления инструкций так и их стоимость, впрочем как и размеры кеша и тд (ссылке выше на патч.. для Zen5 указано что это копипаста Zen 4 на данный момент в коде на гитхабе) для конкретной итерации архитектуры конкретного производителя. Так есть и у Intel так и других архитектур(не x86).vmsolver: ↑ 15.08.2024 13:48 vdemeshko
Это тот редкий (:)) случай, когда Scoffer прав, компилятор действительно никак не влияет на ОоО механизм в процессоре, никак не учитывает его параметры и так далее. Сам подумай, если бы компилятор что-то подстраивал под ОоО окно одного процессора, то что должно быть у процессора с другим ОоО окном, медленней работать? А не должно быть такого, поэтому нет, переупорядочивание это сугубо внутренняя функция процессора, у каждого она реализована по-разному и это дело только процессора, компилятор абстрагирован от этого механизма и на него не влияет и ничего не подстраивает.
По сути, компилятор не знает о ОоО механизме, ему не важно, он просто формирует оптимизированную последовательность из ограниченного набора инструкций, а исполнением занимается железо, оно само разбирается как и что ему делать, причем в реальном времени, о чём компилятор не знает и в принципе знать не может (доказано Итаниумом, где компилятор пытался оптимизировать код так, чтобы все конвейеры были заняты - это приблизительная аналогия контроля/замены компилятором ОоО окна, и получалось у него откровенно плохо, настолько плохо, что многие даже не знают про Итаниум).
-
Inqizitor2022
Member
- Звідки: Харьков
Можно вкратце кто виноват? Моё мнение - индусы облажались снова и по хорошему, нужно винду оптимизировать до вида, когда фпс будет одинаковый
-
AndP
Member
- Звідки: Kyiv
Перенес в нужную тему
-
vdemeshko
Member
- Звідки: Киев
Покупатели те которые early adoptersInqizitor2022: ↑ 16.08.2024 16:27 Можно вкратце кто виноват?
-
AlexKuzovkov
Member
А от і тест с на 24Н2 вінді.
- спойлер
-
NST1983
Member
- Звідки: Україна
Срані індуси https://prnt.sc/il-L94zIkgE2
Востаннє редагувалось 26.08.2024 14:38 користувачем NST1983, всього редагувалось 1 раз.
-
AlexKuzovkov
Member
А що тепер Інтел буде робити? Там темає апу.NST1983: ↑ 26.08.2024 14:34 Срані індуси