Свежие тесты Intel Core i9-13900K: более 40 тысяч очков в Cinebench R23 при 345 Вт энергопотребления

[bigfAN007]

Можна версію з афтографом Грети Тунберг на кришці?

Особлива грета свою пісеньку під дудку свр вже відспівала та успішно змита

Два раза прочитал, пока не понял, что речь идёт про песню.

[ViPo]

Два раза прочитал, пока не понял, что речь идёт про песню.

swan song мабуть.

[WWQ]

Наверняка же конкуренции никакой, правда?

Т.е. вы одному процу одного производителя противопоставляете 2 разных от другого? Интересный подход, не встречал таких.

Как предлогаете ими пользоваться?, 2 машины собирать или камни перетыкать в зависимости от задач?

[Lorichic]

Т.е. вы одному процу противопоставляет 2 разных? Интересный подход, не встречал таких

Интел якобы универсальней, и поиграть норм и поработать, но это не так, многозадачность хромает

спойлер

1) 12900K (12900KF)
Из плюсов - относительно свежая модель, надежность в плане совместимости с другими комплектующими, возможность использования более новой DDR5
Из минусов - слабые результаты по рендерингу как в фоне так и в активном режиме. По многим отзывам в фоновом режиме проц сбрасывает рендеринг на свои 8 недоядер, в итоге рендер начинает сильно тупить. Как выход - нужно постоянно держать рендер в активном режиме, лишая себя возможности заниматься параллельно с рендером другими задачами. Да и в активном режиме результаты слабее рязани.
Также большее энергопотребление в сравнении с главным конкурентом 5950Х

2) 5950Х
Из плюсов - более быстрые показатели рендеринга, меньшее энергопотребление, полноценные ядра не губят рендер в фоне
Из минусов - к середине 2022 уже устаревший проц со старой DDR4, напряжный бэкграунд в плане танцев с дровами и прочих нестабильностей и ненадежностей.

Отправлено спустя 2 минуты 4 секунды:

2 машины собирать или камни перетыкать в зависимости от задач?

Вот именно, 12900к под рендеринг, отдельно машина под ютубчик/интернет

[Liquidator]

Хороший проц, чтобы греться зимой, когда русня развалит ТЭЦ. Знать бы только, что будет электричество)

Открою для тебя "тайну", про то, что ТЭЦ в первую очередь спроектированы вырабатывать электричество, а отборы части уже отработавшего на первых ступенях турбины пара для теплообменников отопления и гороячего водоснабжения лишь один из способов увеличения общего КПД электростанции Поэтому, дружище, если уже встанет ТЭЦ - то ни тепла, ни тем боле электричества не будет

[manbearboar]

К середине 2022 уже устаревший проц со старой DDR4, напряжный бэкграунд в плане танцев с дровами и прочих нестабильностей и ненадежностей.

"Устаревший" это почти синоним обкатанный. Какие там нестабильности?
Дрова на процессор, рили?

И в чем устаревшесть тогда проявлялся, если он здесь и сейчас лучше для работы?

[Lorichic]

manbearboar
Это не моё мнение, цитата с форума, можно с этим согласиться или нет, я акцентировал внимание на работе приложений 12900к в фоне, задачи начинают выполняться на е-ядрах, P-ядра не задействуются, для многочасовых рендерингов такая работа планировщика напряжна по времени, или во время рендеринга не уводить проект в фон

[WWQ]

Lorichic
"Нюансы" с мелкоядрами нынче решены в В11, хотя если ты постоянно рендеришь на В10 то проще афинить нужные тебе потоки под нужную софтину и не парится с автоматикой. У меня так на рабочей машине сделано, 14\28 выделено под рабочие нужды и 4\8 всегда болтаются свободными, а то что там что-то "прогонится" не за 11 часов, а за 10 с половиной, меня вообще мало волнует... плюсом идет шикарный отклик системы в нагрузке... и можно еще чем-то заниматься параллельно.

[Lorichic]

"Нюансы" с мелкоядрами нынче решены в В11

Эти нюансы надеюсь будут решены в новом планировщике процессора, а пока как есть, или рендерим и не трогаем камп или миримся с производительностью мелких ядер в фоне

[WWQ]

Lorichic
планировщик делает то что "говорит" ему драйвер... и не более того. Сам по себе проц(планировщик) ничего самостоятельно не решает.

[Lorichic]

WWQ
Открой диспетчер задач с поядерным мониторингом, запусти синебенч cr15 минут на 10 и сверни его в трей, посмотири видосик на ютубе, новости почитай, потом проанализируй загрузку ядер, если задача в фоне не использует AVX инструкции с вероятностью 99% она будет висеть на Е ядрах

[WWQ]

Lorichic
у меня нет проца 12 поколения, даже на работе, проверить лично не могу.

Отправлено спустя 33 минуты 5 секунд:
я писал бумажку на тестовый 12600кф, но началась война и работы поубавилось, а все решения ушли в долгий ящик.

[ronemun]

Ну врешті решт користувачі зрозуміли, що потужність вимірюється у Ваттах. А Інтел швидко пішов на зустріч тім, хто бажає собі потужний комп'ютер! Якщо що, просто жартую.

так давно це зрозуміло хто очі роззув, а не тільки на частоти і кількість ядер дивиться - все вирішує теплопакет. Два 32 ядерних Epyc по 280 Вт завжди будуть знаачно потужніші за один 64 ядерний з 280 Вт. І завжди проци з високочастотними ядрами коштували знааачно дорожче ніж навіть проци з більшою кількістю ядер тої ж архітектури, але нижчими частотами. Тому якщо тобі тре швидший відгук, а це 80% задач, то вибір очевидний. І ясно що на вищій частоті буде вище і споживання, і в геометричній прогресії. Кому не подобається - не беріть.
Зарашні проци дуууже швидкісні, і складні - кожен такт конвеєра вимагає суперпотужного планувальника, шин, кешів і т.п. - це все енергія. зарашнє ядро це міліарди транзисторів (включно з кешами)

IInLight ну скільки вже можна пхати цей 5800х3д який всюди в тестах зливає 12900, і навіть 12700, крім деяких ігрушок - навіть по твоєму графіку видно що розкид від -13 до +14 (26 не рахую - одна невідома ігра з 50 непоказник)
Також в Chrome Compile і очевидно що 8 ядер Aldera догнали 16 Zen3 з допомогою всього навсього 8 низькофективних низькочастотних однопоточних ядер, які разом рівні максимум 3 нормальним ядрам. Тобто рахунок десь 11 Алдер=16 Zen3.
Ну і 1-ше місце 5950 тут явно натянуто, не позорились би: 6 очок більше з 3130 це ж 1/500 - меньше статистичної помилки.
А що вже казати про відсутність DDR5, PCIe 5, графіки на 256 ядер, штучного інтелекту, відеокодека і інтерефейсів на 8к монітори

Відправлено через 19 хвилин 1 секунду:

Одне не розумію, навіщо було е-ядра обєднувати аж по 4 шт- додаткові затримки, тратити на них стільки повільного кешу л2=4х4=16 мб, який не можна використати іншим ядрам, та ще й приєднувати кожну четвірку в кільце всього через 1ну станцію

Е-ядра объединили в 4-ядерный кластер для того, чтобы кольцевая шина была как можно меньше. Ведь если каждое е-ядро имело бы свою станцию, то представьте как быстро бы вырос размер кольца. Считаем у 12900: uncore c КП, 8 ядер, графика, два кластера по 4 ядра, получается 12 станций, а без кластеров было бы: uncore c КП, 8 ядер, графика, 8 е-ядер, итого 18 станций, что много как для десктопа, задержки будут высокие. У 13900 было бы аж 26 станций, что уже за гранью разумного. Значит станции надо экономить, вот и выбрали 4-ядерный кластер для е-ядер, оставив как было ранее во всём остальном.

Я не удивлюсь, если в будущем, и р-ядра будут соединены, например, по два ядра на станцию. Полосу станции конечно же увеличат, например, в TigerLake уже увеличили в двое.

Два кольца это плохо. Ведь кольцо это не просто шина данных, она системообразующая, она "сшивает" как кеш L3 в единое целое, так и все остальные ресурсы на кристалле. А второе кольцо получается будет прилеплено "с боку" и занимать две станции основного кольца, не садить же 8 е-ядер на одну станцию, вы и от 4 е-ядра на одной станции не в восторге, а что будет при дальнейшем масштабировании? Будет всё хуже и хуже, и не однородно. В общем, текущее решение это меньшее зло.

И ещё раз, кольцо это ещё и "связка" кеша L3 в единое целое, второе кольцо тоже будет с кешем или без? Если с ним, то в системе получится два L3 кеша, что не упрощает систему от слова совсем, тогда (основной)L3 не будет играть роль LLC (Last Level Cashe), а именно для этого он и нужен. А если там второго кеша L3 не будет, то тоже хорошего мало, ведь так или иначе будут увеличенные задержки от е-ядер до L3 и проблемы с полосой к е-ядрам из-за "бутылочного горлышка" между кольцами.

В общем, второе кольцо не нужно, всё усложняется и при этом ничего не улучшается. Тогда уже лучше перейти на сетку, она хотя бы снимает(отодвигает) проблему полосы при масштабировании, но тоже не идеал, и для средних и бюджетных камней оверкилл и вообще не нужна, делать два решения для десктопа Интел скорее всего не захочет. Пока кольцо справляется менять его никто не будет, а схемотехнические трюки ещё даже не начали исчерпываться, поэтому кольцо в десктопе будет ещё долго. Хотя, надо глянуть что даст тайловый дизайн системы в этом плане.

Яж писав що необхідно було е-ядра в окреме кільце, а основні ядра зі своїм кільцем навпаки мали б меньше станцій, і навіть без системного агента і графіки - їх теж в друге кільце. В Xeon v4 така конструкція давала дуже малі затримки між ядрами, навіть з різних кілець - 45 нс приблизно - а зараз кільця значно швидші. А так виходить що доступ до е-ядер дає приблизно 50 нс, крім тих що всередині четвірки, і то в них під 30. Це і логічніше, полегшує розподіл навантаження при плануванні. А виграш в 12 МБ (4x4-16*0.25) кешу для 13900 досить значний: +33%. В АМД теж кожен чіплет має своє кільце, а потім ІО чіп своїм хабом їх обєднує - і при потребі ядра лізуть в кеш L3 іншого чіплета - він ніби загальний, але віддалений з шаленою затримкою біля 80-120 нс. В Інтела від сили було б 50нс.

[vmsolver]

Яж писав що необхідно було е-ядра в окреме кільце,

Этот вариант я также рассматривал

а основні ядра зі своїм кільцем навпаки мали б меньше станцій,

Как я написал выше, нет, если 8 е-ядер соединить своим кольцом, то эту шину надо как-то соединить с основным, и на это пойдут как минимум две станции как основного так и добавленного. В итоге, что пнём об сову, что совой об пень, только с двумя кольцами сложнее, хуже и дороже. Теперь если е-ядер будет уже 16. Второе кольцо будет уже большое и с высокими задержками из-за размера кольца, полосу шин соединяющие кольца тоже надо увеличить, то есть соединить 4 станции одного кольца с 4-мя станциями другого, а иначе - бутылочное горлышко по полосе, и в любом случае пенальти по задержкам, при многопоточной нагрузке - огромное в случае бутылочного горлышка. А многопоточность, это то ради чего всё это было задумано...
В итоге, основное кольцо будет такое же по количеству станций как и в грядущем 13900, но будет ещё второе кольцо с дополнительными задержками и более сложной коммутацией шин. И снова, такая конфигурация не будет лучше текущей, будет сложнее и хуже.

і навіть без системного агента і графіки - їх теж в друге кільце.

А на мой взгляд - там им делать нечего, они должны быть в "основной" части процессора, а не в дополнительном огрызке.

В Xeon v4 така конструкція давала дуже малі затримки між ядрами, навіть з різних кілець - 45 нс приблизно - а зараз кільця значно швидші. А так виходить що доступ до е-ядер дає приблизно 50 нс, крім тих що всередині четвірки, і то в них під 30. Це і логічніше, полегшує розподіл навантаження при плануванні. В АМД теж виходить кожен чіплет має своє кільце, а потім ІО чіп своїм хабом їх обєднує - і при потребі ядра лізуть в кеш L3 іншого чіплета - він ніби загальний

У меня нет данных про старые Зионы (мне просто не нужно), но я вижу, что Интел спроектировала гибридную систему так, чтобы кольцо было одно и оно имело наименьшие размеры, при прочих равных это всегда означает наименьшие задержки и отсутствие бутылочных горлышек. Другими словами, то решение, которое Интел реализовала имеет топологические преимущества и вы его ничем не перебьёте, любая более сложная топология будет хуже в плане задержек и определённо будет вызывать беспокойства по поводу масштабирования полосы. Когда я выше писал, что не удивлюсь если на одну станцию повесят два р-ядра, то это именно про это, такое решение позволит упростить топологию соединений и снизить латентность, но и имеет свою цену.

По поводу латентностей, посмотрел эту статью. Там много чего сказано и про смущающие вас 50 нс, но числа вы попутали.
Латентность между р-ядрами можно условно принять как 30 нс, латентность между р-ядрами и е-ядрами 40 нс, латентность между е-ядрами в одном кластере 50 нс (!), латентность между е-ядрами в разных кластерах чуть менее 40 нс. Не особо и катастрофа за исключением задержек внутри кластера (об этом ниже ещё).

Так же там сказано, что увеличенные кеши вносят свой вклад в эти задержки, так как чем больше кеш тем больше у него задержка. А значит не стоит от 2 МБ кеша ждать задержки как у условно 256 КБ кеша, учитывайте это.

Кстати, по поводу нелогичности, почему межядерная латентность в кластере е-ядер больше всех остальных там сказано так (это забавно, интересно как с этим будет в i9-13900K):

What’s however a bit perplexing is that the core-to-core latencies between Gracemont cores is extremely slow, and that’s quite unintuitive as one would have expected coherency between them to be isolated purely on their local L2 cluster. Instead, what seems to be happening is that even between two cores in a cluster, requests have to travel out to the L3 ring, and come back to the very same pathway. That’s quite weird, and we don’t have a good explanation as to why Intel would do this.

И напоследок

але віддалений з шаленою затримкою біля 80-120 нс

Вот чтобы подобного, хоть и в меньших масштабах, не было, Интел и не делает несколько колец. Проще топология - всегда лучше.

[ronemun]

vmsolver
дякую що відповіли на мій пост Ви вірно звернули увагу на дивні затримки між е-ядрами
Переклад: Однак дещо дивує те, що затримки між ядрами Gracemont надзвичайно повільні, і це досить неінтуїтивно, оскільки можна було б очікувати, що узгодженість між ними буде ізольована виключно на їхньому локальному кластері L2. Натомість, схоже, відбувається те, що навіть між двома ядрами в кластері запити мають виходити до кільця L3 і повертатися тим самим шляхом. Це досить дивно, і ми не маємо хорошого пояснення, чому Intel це зробила


Тут важко розібратись в таких значних затримках. Хоча і логічно ніби якщо свій кеш дууже повільний, але тоді навіщо тратити так багато кешу (16 МБ в 13900) з такою малою користю. Виходить що е-ядра взагалі окремо вчеплені до основного кільця поза їх кеш L2, через свій хаб/кільце, тобто якби паралельно - одночасно станцією користується хтось один. Але тоді виходить що доступ в L3 (3МБ блок, 2-3 найближчих це 6-9 МБ) швидший ніж в L2 (4МБ на 4 ядра) І доступ до ядра в чужому кластері швидший. Напевно через вищі частоти в основному кільці і його ширину. Тоді ще більше шкода 16 МБ L2

Якщо повернутись до схеми як у Xeon v3-4:
1. L2 кеш всього 0,25 - менша латентність. Кеш був інклюзивний - він моментально синхронізувався з L3. І це тянулось ще з 45 нм, отже на 7 нм взагалі не помітно. Ну або 512 КБ ексклюзивний, як в АМД - взагалі без втрат на інклюзивність. Якщо подивитись на кристал в АМД L2 з тегами і інтерфейсом взагалі непомітний на фоні ядра і L3
2. 16 е-ядер + 4 блоків кешу L3 по 4 МБ + 4 на обмін це всього 24 станції, майже як в основному кільці: 8 р-ядер + 8 кеш + 4 обмін + DRAM +PCIe/DMI + графіка =23 (L3 по 4 МБ щоб зрівняти кількість з 13900 = 36 L3 +4*4=36+16=52). Дійсно, 2 великих кільця, тільки доступ між е-ядрами, а тут їх аж 16 штук, був би не за 50, а 30 нс, як в основному кільці. Але збільшились би між p- і е-ярами до 45-50, як у Xeon v4. Тут не розбереш що краще, але думаю що обмін в основному буде йти між однаковими ядрами - немає сенсу між різними через 2 кратну різницю в продуктивності = частота х IPC (в 2,5 раз враховуючи гіпертрейдінг). Також друге кільце, можна робити вужчим у 2 рази через малу кількість кешу і повільніші ядра - адже загальна продуктивність його все одно у 2-3 рази меньша ніж у основного. Хоча і зараз у частини е-ядер 40 нс між собою - в чужі кластери, а в 13900 їх буде аж 3 чужих
Але загалом в Інтел не погано зробили, тут ви праві, попарне зєднання p-ядер, при умові зменшення затримок між ними, теж гарна ідея

[MessiaH]

охлаждать только чиллером?)

[vmsolver]

vmsolver
"Однак дещо дивує те, що затримки між ядрами Gracemont надзвичайно повільні, і це досить неінтуїтивно..."

Лучше перефразировать:"затримки між ядрами Gracemont надзвичайно великі...". Это меньше вводит в заблуждение, не все сразу понимают, что медленные задержки (повільні затримки) это высокие задержки. Я, например, визуально аж "споткнулся" когда увидел слово slow там.

Тут важко розібратись в таких значних затримках. Хоча і логічно ніби якщо свій кеш дууже повільний

Там же сказано, что они предполагают, что запросы даже внутри кластера наверное идут всё равно через кольцо, поэтому там так неоптимально получилось. В любом случае, я не думаю что так останется и в грядущем 13900. Хотя, е-ядра в многопотоке дают не плохую прибавку даже с подобными неоптимальностями, что говорит о стратегическом успехе всей задумки, даже не смотря на некоторые нюансы тактического уровня (надо меньше смотреть Арестовича).

але тоді навіщо тратити так багато кешу (16 МБ в 13900) з такою малою користю.

Как это зачем? Проигрываем немного в чём-то одном, но заметно выигрываем в другом. Несмотря на всё это, задержки большого кеша всё равно меньше чем задержки ОЗУ, поэтому он свою функцию выполняет хорошо, а большой кеш делает это ещё и эффективнее. Поэтому нет, не зря.

Виходить що е-ядра взагалі окремо вчеплені до основного кільця поза їх кеш L2, через свій хаб/кільце, тобто якби паралельно - одночасно станцією користується хтось один. Але тоді виходить що доступ в L3 (3МБ блок, 2-3 найближчих це 6-9 МБ) швидший ніж в L2 (4МБ на 4 ядра) І доступ до ядра в чужому кластері швидший. Напевно через вищі частоти в основному кільці і його ширину. Тоді ще більше шкода 16 МБ L2

Не знаю почему вы сделали подобный вывод, к кольцу соединён кеш L2, к которому по четырём независимым каналам подключены е-ядра, запросы от ядер идут в контроллер кеша L2, а вот он уже решает что делать дальше, искать у себя в тегах и одновременно послать запрос в "кольцо" (читать: в L3) или в какой-то последовательности, надо разбираться с политикой синхронизации.

Чтобы понимать ту таблицу, надо сначала обратить внимание что такое вообще межядерная задержка, я её понимаю так, что одно ядро работало с некоторыми данными, затем второе ядро запросило эти данные, вот время этого запроса и приведено в табличке. Ещё раз, первое ядро прочитало из памяти некоторые данные, что-то делало с ними, затем другое ядро запросило данные с этих же адресов. В итоге, второе ядро поискав эти данные у себя в L1D словила промах и отправляет запрос в L2, теперь он у себя ищет в тегах, видимо политика синхронизации такова, что запросы в любом случае идут в L3 и оттуда ждут ответ, и только потом второе ядро получает запрошенные данные. То есть 10нс пенальти связано не с задержками L2, а задержками синхронизации с L3, даже если она не нужна, я так это понимаю.

Далее, забудьте о частях кеша L3, нет никаких частей, есть весь L3, кольцевая шина сшивает все части в единое целое и работает оно как единое целое, даже не смотря на свою распределённость, данные в L3 размазаны по всем частям этого кеша чередованием, поэтому любой запрос распространяется по всему кольцу (а на всякие оптимизации мы обращать внимание не будем, это внутреннее дело кеша как именно он оптимизирует запросы). А по поводу 16 МБ L2 жалеть не надо, они будут работать на все 100%.

Якщо повернутись до схеми як у Xeon v3-4:
1. L2 кеш всього 0,25 - менша латентність. Кеш був інклюзивний - він моментально синхронізувався з L3. І це тянулось ще з 45 нм, отже на 7 нм взагалі не помітно.

Вот только на 7нм можно позволить себе кеш заметно больше и повысить производительность (== уменьшить простой железа на latеncy bound алгоритмах) много где, а небольшое увеличение задержек не сильно повлияет на общую картину.

2. 16 е-ядер + 4 блоків кешу L3 по 4 МБ + 4 на обмін це всього 24 станції, майже як в основному кільці: 8 р-ядер + 8 кеш + 4 обмін + DRAM +PCIe/DMI + графіка =23 (L3 по 4 МБ щоб зрівняти кількість з 13900 = 36 L3 +4*4=36+16=52). Дійсно, 2 великих кільця, тільки доступ між е-ядрами, а тут їх аж 16 штук, був би не за 50, а 30 нс, як в основному кільці.

О божечки в 13900 будет всего 14 станций (системный агент, 8 р-ядер, графика, четыре е-кластера), а вы про 24 говорите... Астанавитесь... (с)
Я выше себе надоел повторяя про "сложно и не надо" и про сложность топологии.

Але збільшились би між p- і е-ярами до 45-50, як у Xeon v4.

Так 30 или 45-50?

Тут не розбереш що краще,

Нечего там разбирать, чем проще тем лучше, и Интел сделала как лучше.

але думаю що обмін в основному буде йти між однаковими ядрами - немає сенсу між різними через 2 кратну різницю в продуктивності = частота х IPC (в 2,5 раз враховуючи гіпертрейдінг).

В шине там общая полоса важна, ядер же много.

Також друге кільце, можна робити вужчим у 2 рази через малу кількість кешу і повільніші ядра - адже загальна продуктивність його все одно у 2-3 рази меньша ніж у основного.

Считайте, что интеловцы сделали идеальное кольцо, как и любое идеальное железо оно несуществует, так и со вторым кольцом, его нет, но всё работает

Хоча і зараз у частини е-ядер 40 нс між собою - в чужі кластери, а в 13900 їх буде аж 3 чужих

Посмотрим как сделают. В целом и то что сейчас катастрофой не является, но не хорошо конечно. С другой стороны это возможно следствие какой-то ошибки, которую в 13900 должны исправить.

Але загалом в Інтел не погано зробили, тут ви праві, попарне зєднання p-ядер, при умові зменшення затримок між ними, теж гарна ідея

В Интел должны моделировать много разных вариантов и выбирать оптимальное, не злобные же они буратины для себя, а значит есть эффект предсказуемости в общих вещах.

[ronemun]

vmsolver

кільце Xeon v4 має такі можливості
1. блок кешу, який знаходиться напроти ядра, має затримку всього 1 такт. Мається на увазі шина, а не сам кеш - пошук в кеші це інше.
2. Але для чужих ядер це все одно інша станція, тому я їх порахував як 2 окремих, адже одна станція обслуговує або ядро, або кеш. Кожна додаткова станція це 12 тактів - тобто 3нс для частоти 4 ГГц, на якій працюють e-ядра. Сумарно в средньому буде мінімум 2 запити, отже 24 такти на станцію. Теж саме і в Alder. Але, оскільки е-ядра значно слабші за p-ядра, до них меньше звернень, отже завантаження шини меньше.
3. кільце має 2 напрямки, і дані будуть йти по оптимальному, тобто в середньому максимум 3 чужих станції для 8 ядер, 9+1 нс, якщо в своєму блоці L3 промах. По оптимальному тому що ще в 2015 році кожна станція знає де які дані знаходяться і відразу вибирає правильний напрямок
4. зєднання між кільцями не на одному кінці, а мінімум двох, тобто через кожні 4-5 станцій, що дозволяє оптимізувати маршрути між кільцями і не ганяти дані по всьому кільцю. І не тільки на 2 кільця, а й 3, тобто зліва і справа, якщо є. Таким чином 16 е-ядер, очевидно, розбили б на 2х8.
5. 18 ядер Xeon v4 вимагали 5,5 млрд. транзисторів, і це з 6 каналами памяті і 40 ліній PCIe, 45 МБ кешу L3 і 4,5 L2 (а не всього 20 як я попонував для 16 е-ядер), 2 кільцями по 10 станцій (ядро + кеш), 3 QPI по 20 ліній, ну і інтегрованим контролером живлення і управління. І то затримка в кешах була максимум 40-45 нс. Очевидно, що 16 е-ядер значно простіше, тим більше на 7 нм і вищій середній частоті

[IInLight]

Не приписывайте мне речь шла об архитектуре, вот я и сравнил одну архитектуру с другой, на примере представителей этих архитектур

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

8 низькофективних низькочастотних однопоточних ядер

Ууу как пригорает, так мне не жалко, вот ещё

спойлер

И как быстро " высокоэффективная " архитектура Интел превратилась в малоэффективную в сравнении то с процессором вышедшим на год ранее
П.с. не бывает обращений в "чужой" л3 кеш, таких инструкций просто не существует, ядру/контроллеру "виден" только уровень "над" ним, то есть единственный путь ядро->свой л2->свой л3->л4 если есть->драм и по той же цепочке обратно.

[ronemun]

IInLight
1. яку мало ефективну - різниця в 3 кадра зі 180 = 1/60 = 1,66% - це статистична похибка, явне нятягування сови на глобус щоб поставити AMD на 1 місце
2. П.с. не бывает обращений в "чужой" л3 кеш, таких инструкций просто не существует, ядру/контроллеру "виден" только уровень "над" ним, то есть единственный путь ядро->свой л2->свой л3->л4 если есть->драм и по той же цепочке обратно.
Ясно що не код звертається, для нього все один адресний простір, а от хаб чи кільце/я, куди приєднане ядро, створені так ніби всі блоки кешу є одним цілим, щоб не дублювати дані і прискорити пошук: в 16-32-64 ядерному проці кількість нових даних така велика що синхронізція кешів стає неможлива без централізованого управління і зберігання, інакше б дані в кешах дублювались багато раз і дуже засмічувала б трафік, а доступ до DRAM в 200-300 тактів проца це взагалі смерть. І звичайне ніяке дерево L2-L3-DRAM там не обовязкове, це для дітей написано, а логіка складніша - де які дані знаходяться йде постійна розсилка тегів між хабами/станціями, щоб при потребі не тратити час на запит, а відразу знати в якому напрямку рухатись і куди треба звернутись поки дані не витіснили в оперативу. Ще й до того кількість кроків прорахована автоматом щоб по коротшому шляху пройти. Але при цьому врахувати всі інші запити і ефективно розподілити можливості. Для цього в АМД/Інтел і працює орава суперспеців. АМД недаремно в якийсь IO чіп запхала 9 млрд. тринзисторів, при тому що Інтел хватило 8 млрд щоб зробити проц на 10к доларів - Xeon 8280 на 28 ядер/65 МБкешу/6каналів DDR/56 PCie/3UPI це ще 60 ліній - фактично тіж можливості по зєднанню але ще 28 ядер/65 кешу зєднаних супер кільцями
Прочитайте хоча б конкретні описи робити проців і всіляких фіч по зменшенню латентності і максимального використання кешів.