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

Обсуждение статей и новостей сайта
Автор
Повідомлення
man1242
Member
Аватар користувача

Повідомлення

vdemeshko: 15.08.2024 11:29 Подозреваю что дело в поддержке компиляторами в линукс новых архитектурных изменений в Ryzen 5 в том числе:
As improved predictions and instructions are coming through the wider pipeline, AMD needed to make improvements to its instruction dispatch and execution engine. This engine now includes eight-wide instruction dispatch and retire capability each cycle, an increase from the six of Zen 4. With more instructions comes the need for improved scheduling, and to this end AMD redesigned its ALU scheduler, which is now more unified than that of Zen 4. Zen 5's retire queue/reorder buffer is 40% larger than the 320 ops of Zen 4 at 448 instructions deep, giving the CPU a wider window of instructions for out-of-order execution. The Arithmetic Logic Unit (ALU) count has been increased to six from Zen 4's four.
Это вообще существенное изменение за 10ки лет архитектуры х86 если верно помню с OoO исполнением инструкций. Где то было интервью , когда представитель АМД сказал что они закладывают базу для последующих архитектурных изменений в процах и софт несколько лет будет догонять их - то есть они готовят почву для будущих поколений. То есть в линухе компилятор может генерировать оптимизации под расширенное окно выполнения команд для этой архитектуры. Но это так чисто предположения так как мелкомягкие более инертные обычно и очередным обновлением винды могут что то выкатить.

Отправлено спустя 10 минут :
В линуксах ситуация шиворот на выворот - поддержка оптимизаций под процы намного впереди чем под видяхи ))) сами понимаете сервера то на чем и где оно быстрее надо ))
9700х навалят до 120ват и кушать подано :lol:
Как раз 10% прирост выйдет :laugh:
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

Scoffer
если врено помню - не совсем.. то есть да - это храдварная фича, но со своим набором ограничений. Грубя говоря блэк бокс, но код извне вроде как рассчитан на определенные ограничения и должен учитывать границу расширения этих ограничений. Что то аля minimizing data dependencies, utilizing branch prediction effectively, and optimizing cache usage. То есть косвенно можно повысить эффективность работы OoO учитывая его расширения на уровне оптимизации кода. Речь конечно не о каком то прямом влиянии на OoO на уровне кода..
Scoffer
Member
Аватар користувача

Повідомлення

vdemeshko
Компілятор не компілить під конкретну мікроархітектуру, немає такої опції. Компілятор компілить під всі проци з заданим набором команд. Максимум що може компілятор це перевірити чи проц є інтелом :laugh:
До того ж покращення що завезли в зен5 не ламають логіку роботи процесора, він просто тепер може потенційно більше команд за такт пережувати, якщо знайде їх в буфері переупорядкування, для цього жодних змін в коді робити не потрібно. Звичайний мінорний мікроархітектурний ап, інтел так вже сто раз робив.
Востаннє редагувалось 15.08.2024 11:58 користувачем Scoffer, всього редагувалось 1 раз.
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

man1242: 15.08.2024 11:34
vdemeshko: 15.08.2024 11:29 Подозреваю что дело в поддержке компиляторами в линукс новых архитектурных изменений в Ryzen 5 в том числе:

Это вообще существенное изменение за 10ки лет архитектуры х86 если верно помню с OoO исполнением инструкций. Где то было интервью , когда представитель АМД сказал что они закладывают базу для последующих архитектурных изменений в процах и софт несколько лет будет догонять их - то есть они готовят почву для будущих поколений. То есть в линухе компилятор может генерировать оптимизации под расширенное окно выполнения команд для этой архитектуры. Но это так чисто предположения так как мелкомягкие более инертные обычно и очередным обновлением винды могут что то выкатить.

Отправлено спустя 10 минут :
В линуксах ситуация шиворот на выворот - поддержка оптимизаций под процы намного впереди чем под видяхи ))) сами понимаете сервера то на чем и где оно быстрее надо ))
9700х навалят до 120ват и кушать подано :lol:
Как раз 10% прирост выйдет :laugh:
до 105W вроде по слухам в новой AGESA :)

Отправлено спустя 3 минуты 50 секунд:
Scoffer: 15.08.2024 11:55 vdemeshko
Компілятор не компілить під конкретну мікроархітектуру, немає такої опції. Компілятор компілить під всі проци з заданим набором команд. Максимум що може компілятор це перевірити чи проц є інтелом :laugh:
До того ж покращення що завезли в зен5 не ламають логіку роботи процесора, він просто тепер може потенційно більше команд за такт пережувати, якщо знайде їх в буфері переупорядкування, для цього жодних змін в коді робити не потрібно. Звичайний мінорний мікроархітектурний ап, інтел так вже сто раз робив.
если gcc с -O2 то совсем не разницы? :rolleyes:

ЗЫ а они тут что то пыхтят щоб пацанам оверклокерс юа было показать :gigi:
https://www.tomshardware.com/pc-compone ... c-compiler
Currently, the Zen 5 support in GCC uses the Zen 4 cost table, but AMD is expected to provide additional optimizations and enhancements in future patches. This ongoing development will further refine the compiler's ability to take full advantage of Zen 5's capabilitie
ок ок.. :D оптимизации не нужны.. компиляторы и так все умеют :rotate:
Востаннє редагувалось 15.08.2024 12:07 користувачем vdemeshko, всього редагувалось 1 раз.
Scoffer
Member
Аватар користувача

Повідомлення

https://gcc.gnu.org/onlinedocs/gcc/Opti ... l#index-O2
Ти десь бачиш тут в описі процесорозалежність? Хоч в якійсь з опцій :rotate:
IvanCh
Member
Аватар користувача
Звідки: Київ

Повідомлення

Scoffer: 15.08.2024 11:55 vdemeshko
Компілятор не компілить під конкретну мікроархітектуру, немає такої опції. Компілятор компілить під всі проци з заданим набором команд. Максимум що може компілятор це перевірити чи проц є інтелом :laugh:
До того ж покращення що завезли в зен5 не ламають логіку роботи процесора, він просто тепер може потенційно більше команд за такт пережувати, якщо знайде їх в буфері переупорядкування, для цього жодних змін в коді робити не потрібно. Звичайний мінорний мікроархітектурний ап, інтел так вже сто раз робив.
тут ти неправду кажеж в gcc можна вказхати архітектуру, це ще ще з ццаря гороха зроблемо.

те що мосовий софт так не роблять то вже інші приколи пов'язані з сумістністю. але скомпілити з оптимізаціями під конкретну мікроархітекруту - це елементарна задача.

опція -march=cpu-type

під тищі різних архітектур причому там і інтел і нано і амд і китайці типу shijidadao
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

ну вот так -O2 -march=znver5 если? ы? под все архитектуры говоришь? :gigi:
Востаннє редагувалось 15.08.2024 12:14 користувачем vdemeshko, всього редагувалось 2 разів.
Scoffer
Member
Аватар користувача

Повідомлення

Хоча насправді там є процесорозалежна опція, але ні в яких вона не в оптимізаціях, а в цільових платформах.
-march=cpu-type називається, і регулює дозволені набори команд.
От тільки враховуй що софт компілиться під найгіршу з цільових платформ.

Відправлено через 1 хвилину 12 секунд:
vdemeshko
Але це ж не оптимізація, чи не так? Це мінімальна цільова платформа. Софт з такою опцією взагалі не запуститься на зен4 і нижче.
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

Scoffer: 15.08.2024 12:13 Хоча насправді там є процесорозалежна опція, але ні в яких вона не в оптимізаціях, а в цільових платформах.
-march=cpu-type називається, і регулює дозволені набори команд.
От тільки враховуй що софт компілиться під найгіршу з цільових платформ.
согласен что оптимизация идет узкая.. но ты утвреждал изначально что таких оптимизаций не бывает под конретную архитектуру ;) но тут тогда используется гарантировано все расширения набора команд. Но если врено помню даже что бы -O2 мог делать более эффетивный универсальный код - поддержку новых архитеткур и расширений инструкций должна быть внесена в компилятор тоже.
Востаннє редагувалось 15.08.2024 12:19 користувачем vdemeshko, всього редагувалось 1 раз.
Scoffer
Member
Аватар користувача

Повідомлення

IvanCh: 15.08.2024 12:11вказхати архітектуру
Яка просто аліас для наборів команд. Які саме команди вмикаються прямо в тому ж хелпі де і ця опція. Там немає ні слова ні про які нутрощі, ширину ОоО і буфери перевпорядкування, що і треба було довести.

Відправлено через 42 секунди:
vdemeshko
Це не та оптимізація, про котру ти віщаєш. Це просто список дозволених команд, і все.
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

Scoffer: 15.08.2024 12:19
IvanCh: 15.08.2024 12:11вказхати архітектуру
Там немає ні слова ні про які нутрощі, ширину ОоО і буфери перевпорядкування, що і треба було довести.

Відправлено через 42 секунди:
vdemeshko
Це не та оптимізація, про котру ти віщаєш. Це просто список дозволених команд, і все.
цитату где я указывал это - я сказал что должны учесть на уровне компилятора - расширения возможности использования OoO для новых архитектур и не более. Были одни ограничения для Zen 4 - стали другие.
Scoffer
Member
Аватар користувача

Повідомлення

vdemeshko
А я тобі ще раз кажу що не повинні. Компілятор до ОоО не має ніякого стосунку.
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

Scoffer: 15.08.2024 12:22 vdemeshko
А я тобі ще раз кажу що не повинні. Компілятор до ОоО не має ніякого стосунку.
ну давай тебя макнем... раз упроно хочешь. в код естественно...
открываем AMD Zen 4 Cost table patch для GCC (в отношении Zen 3)
https://gcc.gnu.org/pipermail/gcc-patch ... 07902.html
+ 14, 10, /* Gather load static, per_elt. */
+ 14, 20, /* Gather store static, per_elt. */
32, /* size of l1 cache. */
- 512, /* size of l2 cache. */
+ 1024, /* size of l2 cache. */
64, /* size of prefetch block. */
/* New AMD processors never drop prefetches; if they cannot be performed
immediately, they are queued. We set number of simultaneous prefetches
@@ -1943,26 +1945,26 @@ struct processor_costs znver4_cost = {
time). */
100, /* number of parallel prefetches. */
3, /* Branch cost. */
компилятору ничего не нужно ведь знать верно ? ведь ничего не нужно знать про увеличения кеша, префетча, изменения латетности влияющих на подготовку данных для OoO ? так ведь? зачем они заморачиваются и что то патчат ? :)
Востаннє редагувалось 15.08.2024 12:50 користувачем vdemeshko, всього редагувалось 2 разів.
Scoffer
Member
Аватар користувача

Повідомлення

vdemeshko
Тут теж немає жодного слова про ОоО. І не буде. Ти плутаєш х з пальцем.
Префетчер це така штука, котра в міру можливостей і везіння заповнює кеш.

Відправлено через 8 хвилин 45 секунд:
А вартіть інструкцій це про те що якщо наприклад зробити ділення це 40 тактів, а програмний аналог через FMA - 15 (були такі прецеденти на деяких архітектурах, не х86), то робимо програмно. Зараз така фігня скоріш за все не зустрічається взагалі.
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

Scoffer: 15.08.2024 12:44 vdemeshko
Тут теж немає жодного слова про ОоО. І не буде. Ти плутаєш х з пальцем.
Префетчер це така штука, котра в міру можливостей і везіння заповнює кеш.

Відправлено через 8 хвилин 45 секунд:
А вартіть інструкцій це про те що якщо наприклад зробити ділення це 40 тактів, а програмний аналог через FMA - 15 (були такі прецеденти на деяких архітектурах, не х86), то робимо програмно. Зараз така фігня скоріш за все не зустрічається взагалі.
у нас как минимум есть In-order front end который подготаваливает в очередь иструкции для OoO pipeline. Как минимум можно указать на его изменение как и на изменение глубины очереди если я верно помню изменения в Zen 5 (как раз есть имзменения кеша инструкций в сторону увеличения и глубины очереди, что нужно для более эффективного использования "широкого окна" OoO)... ты как то упорно дурочка включать стал.. подробно мою цитату про то что есть какое то управление OoO pipeline :rolleyes: если мной утверждалось что можно указать только косвено на изменения ограничений для подготовки данных для него (например больше обьем кеша или снижение его латености). Можно указать на изменение ограничений для более эффективной загрузки OoO pipepline - примерно так звучали мои утвреждения и не более того.
Scoffer
Member
Аватар користувача

Повідомлення

vdemeshko
Не треба там нічого вказувати, розберить як працює ОоО.

Компілятори загалом проводять багато шаманства, але на фронтенді. Не в останню чергу через загальноприйняту SSA-форму, котра не залишає для бекенду багато простору для дії. Хоч які б суперкорисні команди і режими проц не мав, а через SSA буде все одно заюзано мінімум.
Denvys5
Member
Аватар користувача
Звідки: Kyiv

Повідомлення

Компілятори компіляторами, а є мануальні оптимізації "під процесор"
http://www.numberworld.org/y-cruncher/ тому приклад
vdemeshko
Member
Аватар користувача
Звідки: Киев

Повідомлення

Scoffer: 15.08.2024 13:12 vdemeshko
Не треба там нічого вказувати, розберить як працює ОоО.
там произошли фундаметальные изменения какие то за последние 20+ лет с тех пор как в унивреситете изучал архитектуру ЭВМ? мне достаточно глняуть блок схемы современных CPU аля эта
Зображення
але на фронтенді.
я где то утвреждал обратное? ссылку на пост с моим утвреждением что как то компиляторы влияют на OoO pipeline я так понимаю не дождусь?
vmsolver
Member

Повідомлення

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

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

Повідомлення

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

По сути, компилятор не знает о ОоО механизме, ему не важно, он просто формирует оптимизированную последовательность из ограниченного набора инструкций, а исполнением занимается железо, оно само разбирается как и что ему делать, причем в реальном времени, о чём компилятор не знает и в принципе знать не может (доказано Итаниумом, где компилятор пытался оптимизировать код так, чтобы все конвейеры были заняты - это приблизительная аналогия контроля/замены компилятором ОоО окна, и получалось у него откровенно плохо, настолько плохо, что многие даже не знают про Итаниум).
такс.. где я утверждал обратное :gigi: цитату... мои утверждения что он косвенно может влиять через указание изменения ограничений в размере кеша, префетча и тд.. собственно что я вижу в патче для Zen 4 того же в сравнении с Zen 3.. то естьэто может помочь эффективней загрузить пайплайн OoO - вроде только эти утверждения были с моей стороны.. только косвенное влияние - где про прямое влияние на оптимизацию OoO со стороны компилятора я не могу понять нашли в моих постах. Точнее даже не так.. компилятор должен узнать о том, что есть какие то изменения как добавления инструкций так и их стоимость, впрочем как и размеры кеша и тд (ссылке выше на патч.. для Zen5 указано что это копипаста Zen 4 на данный момент в коде на гитхабе) для конкретной итерации архитектуры конкретного производителя. Так есть и у Intel так и других архитектур(не x86).
Востаннє редагувалось 15.08.2024 14:04 користувачем vdemeshko, всього редагувалось 9 разів.
Відповісти