Свіжі прошивки для плат AM5 покращують між'ядерні затримки CPU Ryzen 9000

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

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

Scoffer: 17.09.2024 22:08У амд л3 кеш не ексклюзивний
Если одно ядро не имеет прямого доступа ко всему L3 процессора, в данном случае 64мб, то кеш не общий, так понятно? Можешь сам придумать название, пусть будет не эксклюзивный, предлагай варианты
Scoffer
Member
Аватар користувача

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

Lorichic
Одне ядро в архітектурі зен всіх версій має повний доступ до будь-якої частини л3 кешу, так зрозуміло?) Але до "дальнього" кешу сходити довше ніж в оперативу.
Ти все наплутав з кор квадом. От там не було доступу. Гірше від того теж не було, до речі.

l-m
Різниця в тому що не треба витрачати цілу купу транзисторів на копію кешу в кожному CCD, і все чудово працює і без цього. А кеш займає майже половину чіплету.
l-m
Member

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

Scoffer: 17.09.2024 22:17 l-m
Різниця в тому що не треба витрачати цілу купу транзисторів на копію кешу в кожному CCD, і все чудово працює і без цього. А кеш займає майже половину чіплету.
Ось тут ти починаєш нагадувати того персонажа який вважає що треба просто взяти й зробити 64 ядра та 512 МБ L3 на одному чіпі, а виробники тупі та врєдні на зло цього не роблять.
Як би в Інтел все працювало чудово, то вони б давно зробили 16 P-ядер, а не ліпили геморой де вішають 4 Е-ядра ядра на один лінк кільцевої шини. Та не викидали графіку з кільця, яка тепер немає доступу до Л3-кешу :(
Спробуй поміркувати чому так роблять. Відповідь до речі схожа на те чому АМД досі не вилазить з 8 ядер на один CCX.
А по факту з ростом кількості "абонентів" на кільці воно стає все менш і менш ефективним, ніяким чудово там й не пахне — конкуренція за ПС зростає, латентність погіршується, у того ж 10900K було краще ~1.5 рази, при меншій частоті, деградація очевидна.
Коротше, ніяка кільцева шина не панацея, проблеми масштабування очевидні, та наразі ніяк не вирішені.
При цьому варіант розв'язання цієї проблеми масштабування, як в АМД, ти критикуєш, ах боже, витрачають цілу купу транзисторів, але в замін пропонуєш взагалі не вирішувати її як Інтел. Ну й куди це привело Інтел?
Scoffer
Member
Аватар користувача

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

l-m
Персонаж може іноді і несе пургу, але в даному випадку він правий. В інтелі просто взяли і зробили 108 метрі L3 кешу на одному чіпі і обіцяють розширити їх до 504 метрів в цьому ж поколінні продукції. В IBM вже зараз завезли 360 метрів на один чіп. А графіку прибрали з кільця тому що її виперли на окремий чіплет але тим не менш з'єднали кеш-когерентним протоколом, і графіка все ще має доступ до л3 процесора.
l-m
Member

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

Scoffer: 17.09.2024 23:05 l-m
Персонаж може іноді і несе пургу, але в даному випадку він правий.
Це називається ефект Даннінга-Крюґера, ви з персонажем чомусь вважаєте себе розумнішими за виробників процесорів, від цього й подібні фантазії.
Scoffer: 17.09.2024 23:05 В інтелі просто взяли і зробили 108 метрі L3 кешу на одному чіпі і обіцяють розширити їх до 504 метрів в цьому ж поколінні продукції. В IBM вже зараз завезли 360 метрів на один чіп.
Як дитині малював, а тепер ще й пояснюй...
Чим більше кеш, тим повільніше він працює. Це в основному чисто фізичне обмеження через довжину провідників. Зменшити яку можна кращим техпроцесом, й тоді відповідно зробити більший кеш, який не деградує при цьому у швидкості. Або схитрувати, та зробити його "3D", тобто нарощувати вертикально, що буде фізично ближче ніж збільшувати площу на монолітному "одноповерховому" кристалі.
Тому, якщо якомусь процесу вистачає для повного щастя 8МБ L3, а ми нарощуємо традиційним не 3Д-компонуванням до 108, то стане тільки гірше.
Отже, розмір кешу це завжди компроміс, де шукають оптимальне значення для тих задач де буде застосовуватись процесор. А не банальне більше = краще.
Саме тому існує у процесорів L1 кеш мізерного розміру, та L2. Саме тому, якщо вже дуже кортить зробити гігантський L3 на "одноповерховому" кристалі, то краще зробити його як L4, а L3 залишити оптимально-нормального розміру.

І до речі, там де в Інтел 108 МБ, там ще й 144 ядра, тобто його об'єму все одно критично мало (мізерні 0.75 МБ на ядро). Та ці ядра повільні, й навіть між собою мають латентність по 100+ наносекунд (щось не дуже видно перевагу "на одному чіпі", і це там слава богу ніяка не кільцева шина (задачка на затвердження вивченого — чому?)).
Тобто, в даному прикладі зробили 108 МБ не через те, що це круто й швидко, а, тому що це жлобський мізер нижче якого вже зовсім погано було опускатись. Та вже байдуже на швидкодію цього кешу, тому краще вже так, ніж ніяк. Тобто це знову суттєвий компроміс, а ні яка не перемога де "просто взяли і зробили 108 метрі L3 кешу на одному чіпі". Але щоб це зрозуміти треба хоч трохи розібратись в питанні... але навіщо, ви ж з персонажем краще знаєте :gigi:
Scoffer
Member
Аватар користувача

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

l-m
А купа малих кешів в ряді завдань це ще гірше ніж великий і тормознутий. Береш наприклад бдшечку, запускаєш багато коротких транзакцій на епіку, чудово запускається, швидко працює і все таке. Запускаєш поряд велику аналітичну і все, всрався епік. А інтел чухає, пердить але їде. І таких завдань море. ІВМ як продавець комплексних рішень, про це прекрасно в курсі, тому всі їхні проци малоядерні і багатокешеві. Інтел з амд теж про це в курсі, але вони просто торгують ядрами на розвіс, особливо остання, а не постачають готові рішення і їм начхати. А у мене головняк з конфігураціями.
Мені ці амдшні кеші не в якійсь там теорій, а на практиці створюють проблеми в роботі. Під кожен новий проект приходить новий ефективний менеджер проекту і віщає щось про дешевше більше ядер на розвіс, і на кожному проекті доводиться робити навантажувальні тестування щоб послати його нафіг.
В загальному випадку універсальної альтернативи тупому нарощуванню кешів поки не вигадали.
Зрозуміло?
l-m
Member

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

Scoffer
Зрозуміло, але твої персональні проблеми та образи це не привід вигадувати бозна-що, як ти робив вище.
Та й розмова починалась з десктопних процесорів, повертайся вже на грішну землю від своїх БД, де Епіки з Ксеонами не справляються, й тільки ІБМ щось може.

Scoffer: 18.09.2024 01:21 В загальному випадку універсальної альтернативи тупому нарощуванню кешів поки не вигадали.
Це не так, я вже пояснив вище чому.
Приємний частковий виняток це 3D-кеш. Але й там є деякі свої нюанси, хай не через кеш, який нарощено майже безкоштовно по затримках, так через 3Д-компонування, яке погіршує тепловідвід.
Причому, по тих же Райзенах/Епіках з 3Д-кешем, видно що навіть таке суттєве та чітерське збільшення L3 кешу далеко не завжди дає помітний ефект у швидкодії.
Scoffer
Member
Аватар користувача

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

l-m
В десктопних процесорах чіплети нафіг не всрались просто за визначенням. Якщо в серверах проги давно знайомі з нерівномірними доступами до даних, їм не звикати і це все хоч якось працює, то десктопні проги про це нічого не знали, не знають, і знати не хочуть. Як результат, рейзен 9 не має ніякого значимого приросту відносно райзен 7 на пересічних десктопних прогах, ігрульках наприклад. А кеш значимий приріст вочевидь дає.
l-m
Member

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

Scoffer: 18.09.2024 02:14 В десктопних процесорах чіплети нафіг не всрались просто за визначенням.
А тут я й не сперечаюсь. Це необхідне зло для тих хто хоче більше ядер. Як й Е-ядра в Інтел (які теж "нафіг не всрались просто за визначенням").
Я ж вже пояснив.
Та й справа не в самих чиплетах, як таких. Можна зробити моноліт де буде два CCX по 8 ядер (як було в Зен2 по 4), та це практично ніяк не покращить ситуацію (див Strix Point з 4+8). На це я теж неодноразово натякав вище.
Scoffer: 18.09.2024 02:14 Як результат, рейзен 9 не має ніякого значимого приросту відносно райзен 7 на пересічних десктопних прогах, ігрульках наприклад. А кеш значимий приріст вочевидь дає.
І тому найбільш популярний процесор в ентузіастів для ігор це 7800Х3D, все закономірно.
l-m: 18.09.2024 02:06 Це не так, я вже пояснив вище чому.
Тобто кеші й далі будуть поступово нарощувати, коли це буде дозволяти техпроцес та потребувати софт. Як завжди й відбувалось.
Але ось ця фантазія — тупо вліпимо зараз купу кешу на моноліт та все залітає — це не більше ніж фантазія. Та Інтел з АМД про це знають. Як знають й те, що потім вигідно це не продадуть. Саме тому рішення ІБМ за купу грошей і є нішевими рішеннями за купу грошей. І саме тому АМД морочиться з 3D-кешем замість звичайного "плаского". І саме тому що я це вже все вище пояснював трохи іншими словами, пора закруглятись :)

Відправлено через 2 хвилини 36 секунд:
l-m: 18.09.2024 01:02 якщо вже дуже кортить зробити гігантський L3 на "одноповерховому" кристалі, то краще зробити його як L4, а L3 залишити оптимально-нормального розміру.
Тим паче я вже написав реально робоче рішення.
ronemun
Advanced Member

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

l-m
ти б перед тим як критикувати хоча б прочитав щось, наприклад
semianalysis
nextplatform
chipsandcheese
semiwiki
gamma0burst.tistory.com
.. на і LinkedIn багат спеців пишуть
Intel Emerald rapids вже більше року як протестований і майже рік як продається - 64 ядра працюють як один кристал по 5 МБ кешу L3 на ядро, сумарно 320, це крім 2МБ L2 на ядро, ясне діло. Але там же ще мережевий кеш (snoop) по 3+ Мб на ядро. А головне що все в сітці, тобто крім свого сусідні 4 банки по 5Мбайт доступні на відстані 1-2 такти мережі, і всі 4 одночасно на вхід/вихід. Якщо ядру дуже тре було б воно може качати і писати з будь-якої клітини, але в реалі цього ніколи не буде потрібно, а якщо все ж тре було б то про це наперед відомо згідно аналізу коду ще задовго до виконання і відповідно планується, а не як тут в статті - взяли і заставили писати кудись чи читати. Такого в реалі немає.
Звичайно, часто є просте перекидування потоків на інші ядра, але на саме виконання це не впливає, адже код перекидується лише тоді коли він буде виконуватись на багато довше ніж саме перекидування.

1. весь брєд про велику затримку кешу у Інтел пишуть люди які елементарного моделювання не робили. Він більший тому що це середня відстань, виміряна в доступі до всіх ядер. Чим більше ядер тим дальша відстань. Але в реалі Інтел має 2-4 МБ L2 і йому дальній кеш L3 непотрібен, сусідніх хватає, а поки вони переповняться дані в оперативу надійдуть. А при зчитуванні взагалі наперед планування руху даних йде ще сотні тактів перед виконанням коду і поки дійде все вже буде поблизу або на відстані пару тактів. Все прораховано при розробці мережі.
2. Всі тестування на Anand сміття порівняно з тестами спеців які пишуть прошивки для проців і тестують в реальних бізнес прогах. Хіба не очевидно, що специ з АМД не могли так лоханутись, тим більше Іо чіп і швидкість IF лінків там та ж що в Zen4. Різниця вийшла через серверне використання - нові Zen5 це 192 або 128 ядер у серверах, по 8-12 каналів памяті, і очевидно що старий спосіб роботи кешу негодився. Зарашні дуже багатоядерні проци більше подібні до відях - там немає сенсу в малій затримці, адже дані перекидуються відразу від багатьох ядер, величезними потоками з кожного чіплета, а не пакетами від кожного ядра, як раніше. Це як на перехрестях доріг мудро збільшують час очікування щоб збільшити час руху потоків і дати більшій кількості машин проїхати зараз, щоб зменшити вплив затримки на старт/стоп. В серверах дуже мала ймовірність що буде 1-2 потоки з чіплета за раз, це хіба що в десктопах, в іграх, і то при потребі негайного доступу є приорітети. Тому зараз приорітет підняти середню швидкість за рахунок збільшення середньої затримки доступу. І потім ця політика перейшла у дескторні 16 ядер Ryzen, де все таки інша ситуація.
3. низькі затримки між ядрами взагалі мало кому потрібні. Згідно даних спеців меньше тритини коду реально синхронізується на пару ядер, а решту тупо працює з банками кешу/ оперативою. І навіть те що синхронізується розподіляється на сусідні вільні ядра заради зменшення копіювання даних. Тобто ці тести просто для статті, а в реалі нікому не здалися. А статті привертають увагу, формують аудиторію, а там гроші від реклами і спонсорів/мракетологів і т.п. Інженери дивляться зовсім інші речі.
l-m
Member

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

ronemun: 18.09.2024 05:41 Intel Emerald rapids вже більше року як протестований
Точно, я вже й забув. Певно тому, що він тільки й зміг що в середньому наздогнати тоді відповідний 64-ядерний Епік, який був ще на Зен4 та всього з 256 МБ кешу (точніше з 8 клятими чиплетами по 32 МБ, хех).
ronemun: 18.09.2024 05:41 64 ядра працюють як один кристал
А їх там два по 32 ядра, чиплети не пройдуть! :mad:
ronemun: 18.09.2024 05:41 по 5 МБ кешу L3 на ядро, сумарно 320
Ой-ой, у Scoffer не дасть тобі просумувати... ну хіба для нього велика різниця між ~60 нс та 75.
ronemun: 18.09.2024 05:41 А головне що все в сітці
А тут кажуть без кільця нема життя.
ronemun: 18.09.2024 05:41 тобто крім свого сусідні 4 банки
Дві, 4 було у Sapphire Rapids.
ronemun: 18.09.2024 05:41 по 5Мбайт доступні на відстані 1-2 такти мережі
Не знаю що таке 1-2 такти мережі, бачу 40 нс у найближчих та найбільш вдало розташованих банок кешу (ядер), та 75 у найбільш віддалених випадках. Порівняй це з 8-9 нс у нормального L3 в Зен 4-5. Про це я вище й писав. Навіщо ви кожен раз наводите приклади які доводять мою правоту?
ronemun: 18.09.2024 05:41 Якщо ядру дуже тре було б воно може качати і писати з будь-якої клітини, але в реалі цього ніколи не буде потрібно
Тобто 5 МБ L3 вистачить всім, так й запишемо :)
waryag
Member
Аватар користувача
Звідки: Суми

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

Не розумію, що заважало АМД потягнути з релізом місяць-другий і релізнути 9000 серію з хай не суттєвим, але помітним випередженням відносно попереднього покоління.
Alligator
Member
Аватар користувача
Звідки: Миколаїв

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

WorthyWizard: 17.09.2024 13:26AMD опять за свое, сначала выпустят несъедобный продукт (никакой прирост производительности/завышенная цена), потом допиливают/снижают цену, но все ревью уже обосрали. С такой тактикой рынок сложно будет отжимать
Когда в противниках, аж один и у него топовые модели плавятся просто от включения для победы нужно просто не деградировать при включение :lol:
dext
Member
Звідки: Dnipro

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

l-m: 18.09.2024 08:00 Не знаю що таке 1-2 такти мережі, бачу 40 нс у найближчих та найбільш вдало розташованих банок кешу (ядер), та 75 у найбільш віддалених випадках. Порівняй це з 8-9 нс у нормального L3 в Зен 4-5. Про це я вище й писав. Навіщо ви кожен раз наводите приклади які доводять мою правоту?
- латентність всього і конкретно L3 міряється в тактах, тобто напряму залежить від частоти: у інтела від ring bugs, у амд від частоти ядер бо L3 працює на частоті ядер
- "нормальний L3" в Zen існує лише в межах 8-ядер і являє собою дуже урізану-оптимізовану версію ring bus спеціально для 8 ядер, без підтримки графіки тощо, тоді як в інтела ring/mesh це повноцінний універсальний interconnect для всього (ядер, графіки, media engine, ram)
- Під "1-2 такти мережі" мається на увазі якщо потрібно більше кешу, то доступ до наступного сегмента буде коштувати +1..2 такти
l-m
Member

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

dext
Спробуй перерахувати 1-2 такти в нс, чи 40-75 нс у такти, та зрозумієш що "мається на увазі" не б'ється з реальністю, тому це був товстий натяк, а не питання.
З точки зору топології у Зен зірка, де центральний вузол це Л3-кеш. Який під'єднаний в іншу зірку вже більш повноцінним interconnect для всього, де центральний вузол це хаб Infinity Fabric. От тут й проблема АМД та простір для покращення, їм треба або модернізувати її, або міняти на щось швидше (з меншої латентністю). А чи моноліт, чи чиплети, це байдуже поки IF має таку продуктивність.
Відповісти