Intel планує повернутися до єдиної архітектури CPU, відмовившись від поділу на P- і E‑ядра

[alexeygalas]

Royal Core

Хах, загуглив щоб детальніше почитати і перший же результат - дана новина

https://www.notebookcheck.net/Jim-Kelle ... 274.0.html
де інкримінують саме початок втілення ідеї Royal Core

[1234waltz]

Це скоріше показник оптимізованості ігрових рушіїв. Інашке би всі ігри показали однаково гірші результати.

У 99% ігор та рушіїв не існує ніяких "оптимізацій" то локу коду на багатопоточності типу HT/SMT. Навіть на консолях на це більшість розробників не заморочуються, це взагалі на стороні ядра ОС та заліза працює. В таке грається тільки спеціалізований сервачний софт та колись балувалась Adobe в своїх продуктах (для окремих функцій та фільтрів).

[n+gibat[]r]

А что случилось? Гипертрейдинг, забытая технология древних, может тоже вернется? Синие дармоеды просто не могут признать, что обосрались с нанометрами и могут только клепать разнородные ядра аля Биг Литтл. Рукожопы даже нормально не осилили 3 нм ТСМС.

Интелбой ругает Интел, докатились

[Васильович]

Intel планує повернутися до єдиної архітектури CPU, відмовившись від поділу на P- і E‑ядра

Чудово. Наступним чекаємо повернення нормального неймінгу процесорів

[vmsolver]

Если ArrowLake-у дать bLLC то у него всё будет в порядке с играми, как сейчас у X3D AMD, в работе и сейчас всё хорошо.
В NovaLake должно быть ещё лучше, потому что новые ядра могут обыграть возможности более тонкого техпроцесса, лучше энергоэффективность, что может побудить реализацию более быстрого SIMD или ещё чего-либо. А вот как реализуют уже увидим в тестах.

[Piter Cantrope]

Як сама по собі вакансія щодо уніфікованих ядер може доводити, що компанія відмовилася від енергоефективних ядер у своїх продуктах? Якщо опублікують вакансію у відділ мобільних чипів то зробимо висновки про відмову від десктопних і серверних проців?

Саме так. І в Інтел і в АМД є команди, які паралельно працюють на різними архітектурами і їх варіантами. Наприклад, в АМД були команди, які працювали над чиплетними апу ще кілька поколінь назад, але в виробництво пішли монолітні. Були команди, що працювали над чиплетами з більшою к-стю ядер ще для 9000 серії, але були і інші команди, і саме їхні продукти пішли у виробництво.
В Інтел теж було купа лінійок і варіантів, які не пішли в виробництво. Тому якась там вакансія абсолютно нічого не означає.

А якщо говорити про e-ядра, то Інтел напхав їх у десктоп, бо треба було показати більше очок в сінебенчі, ніж в АМД. Це було просто "наш отвєт АМД і іхнім шестнадцаті ядрам". Якби в Інтел могли використати більше 8-ми P-ядер, то так би і зробили. Але споживання і затримки були завеликі, тому щоб не відставати на графіках, додали ці e-ядра. Може, в нових Nova Lake цей концепт таки доведуть до розуму для десктопу.
Ну а в мобільних процесорах ці ядра залишаться надовго.

[doc-oc]

Intel планує повернутися до єдиної архітектури CPU, відмовившись від поділу на P- і E‑ядра

Чудово. Наступним чекаємо повернення нормального неймінгу процесорів

#makepentiumgreatagain

[yurius_r]

Як на мене в AMD більш правильний підхід. Звичайні і C ядра не відрізняються наборами інструкцій, IPC та інше, що простіше для планувальника в ОС. Якщо Intel десь потрібні E/LP ядра, то нехай вони будуть однаковими за можливостями і не мішаються з іншими. Як казали вище в десктопі воно нафіг не потрібно, а в портативі як на мене E-ядер достатньо і P там не потрібні взагалі, все одно обмежує швидкодію TDP/охолодження, а не все інше.

[Scoffer]

Не знає, але Ультра серія показала, що відмова від HT разом з 3 кластерами різних ядер не компенсує навіть надшвидкісна пам'ять по ціні золотих злитків, через що люди сидять на 12-14 генах собі спокійно.

Маячня. HT - застаріла технологія з купою проблем. Одна неможливість обчислити реальне завантаження ядра лише чого варта. Було актуально коли транзисторів було мало, а ватів багато. Зараз все з точністю до навпаки. Я в себе на 5950х вимкнув нафіг смт, і це дало буст до відгучливості системи порівняний з переїздом з хдд на ссд. Тим часом сумарна продуктивність по флопсам е-ядер залишає далеко позаду гіпертрейдінги в будь-яких проф прогах. Флопсів більше, ага.

В цих бенчах

А це ваші чиплетики даються в знаки. У амуде монолітні апу теж показують кращі результати, при інших рівних.

[1234waltz]

Маячня. HT - застаріла технологія з купою проблем.

Технологія дуже застаріла, непотрібна та має купу проблем.
Саме тому її додали в кастомізованих арм ядрах HiSilicon Kunpeng в минулому році, в частину арм чипів Хуанга в минулому (NVIDIA Jetson 25 hjre), а Інтел заявили, що будуть повертати в майбутніх рішеннях. Походу в керівництві та інженерних відділах трьох найбільших корпорацій чіпмейкерів одні тупі сидять.
https://www.techpowerup.com/339266/inte ... uture-cpus
[/quote]

[Scoffer]

1234waltz
Серед менеджерів багато недалеких людей, теж мені новина. Ти давай краще скажи як порахувати реальне завантаження ядра з хт/смт. Як точно дізнатись це потік тупить при завантаженні ядра в 10% тому що криво написаний, чи тому що стоїть в чергу за умовним блоком ділення, котрий аж один на ядро, з сусіднім потоком, котрому це ділення теж навіщось треба. Алгоритмик накидай, верхорівнево.

[Intel74320ASuperFin+]

Если ArrowLake-у дать bLLC то у него всё будет в порядке с играми, как сейчас у X3D AMD, в работе и сейчас всё хорошо.
В NovaLake должно быть ещё лучше, потому что новые ядра могут обыграть возможности более тонкого техпроцесса, лучше энергоэффективность, что может побудить реализацию более быстрого SIMD или ещё чего-либо. А вот как реализуют уже увидим в тестах.

Пиковый жор в 700 ватт настораживает у самого старшего камня. Уже 2 8 пин коннектора не хватит на этот керогаз. Охлаждать наверное нужно будет 480/560 мм водой.

Интелбой ругает Интел, докатились

Жду когда штеуд станет конкурентноспособным в нанометрах как в прежние времена. Не получится вечно надеяться на силу своего бренда и просить дотации у Белого дома.

[Scoffer]

Всім кому сильно подобається хт/смт пропоную натурний експеримент. Запускаєте фоном щось що є під рукою, хоч рендер, хоч бублик, хоч бенч 7-зіпа, топом улюблену ігрулю, і пробуєте альттабатись. Якщо вимкнути хт/смт то лаги як рукою знімає.

[1234waltz]

1234waltz
Як точно дізнатись це потік тупить при завантаженні ядра в 10% тому що криво написаний, чи тому що стоїть в чергу за умовним блоком ділення, котрий аж один на ядро, з сусіднім потоком, котрому це ділення теж навіщось треба. Алгоритмик накидай, верхорівнево.

Окей, стоїть в чергу за умовним блоком ділення, катастрофа в чому, в порівнянні з відсутністю гіпертреда? Там що блок Integer Divider один, що блок Integer Multiplier - один. Якщо в тебе в моменті стоїть операцій ділення більше ніж є фізично ядер, то що включено HT, що вимкнено - різниці не буде.

Ну і трошки процитую:

Pipelined/Non-blocking)
У старих процесорах блок ділення міг «завісити» весь конвеєр (stall). У Raptor Lake блок ділення спроєктований так, щоб він не зупиняв потік інших команд. Ба більше, блок ділення з рухомою комою (Floating Point) взагалі винесений на окремі порти (зазвичай P0 або P1, але з іншою логікою), що дозволяє не змішувати цілочисельні розрахунки з науковими/графічними.

[Scoffer]

1234waltz
Так, катастрофа. Неможливо прорахувати завантаження ядра. Планувальник не може точно знати який потік куди треба скинути. В процесорі вже овер 10 портів, і якщо дві проги довбляться в один, то проц звітуватиме про 10% завантаження, а обидва потоки тупитимуть, що і спостерігається в реальності. Особливо велика трагедія на віртуалізації. Саме тому всякі aws graviton'и приницпово не мають смт, білінг заважає робити.

[1234waltz]

Всім кому сильно подобається хт/смт пропоную натурний експеримент. Запускаєте фоном щось що є під рукою, хоч рендер, хоч бублик, хоч бенч 7-зіпа, топом улюблену ігрулю, і пробуєте альттабатись. Якщо вимкнути хт/смт то лаги як рукою знімає.

В цьому експерименті є один практичний недолік.
Беремо свіжу версію 7зіп - вона вміє до 64 потоків утилізувати, в старих версіях було до 32. Тож питання, якщо я буду це робити на умовному Threadripper з 64 ядрами, то там особливо нічого і не помічу. Окрім того, що Threadripper не ігровий проц)
Беремо рендер в фоні. На припустимо 8 ядерному проці, в налаштуваннях рендера ставим 2 фізичних ядра (таке вміють всі рендерилки, навіть лінуксовий кривий KDEnlive), проект який не буде зжирати быльше половину оперативи. Запускаэмо гру яка утилізує 4 ядра з мультипотоком. Що ми повинні відчути при альттабі? Впринципі - нічого.

Ні, якщо запустити рендерилку без ліміту на ядра/потоки, то воно будь-що раком поставить. Тому розглядати такі кейси трошки таке собі. В мене на ноуті при запущеній грі, на доволі несвіжому 6/12 переключення в браузер, стім, геймпасс, торрент месенджер ніяк не відчувається. Якщо поставити Афтер Ефект та запустити рендер на 200 ГБ проект, то ноут що так, що так раком поставить.

[yurius_r]

Якщо вимкнути хт/смт то лаги як рукою знімає.

А що це має довести? Як на мене виглядає як краще завантаження CPU в разі увімкненого HT, і явний недогруз як його виключили . А взагалі питання не в лагах, и швидкості тої роботи, що ви кидаєте в фон своїм alt-tab. А лаги є питанням планувальника ОС

[Piter Cantrope]

Я на своєму 8700G вимикаю SMT. Профіту від нього не бачу ніде.

[МОНАХ]

► Алілуй-йя!
► ... Чи - амінь . Я вже й не знаю, що буде краще ...

[Scoffer]

А лаги є питанням планувальника ОС

У планувальника недостатньо інформації щоб правильно розпланувати потоки гіпертрейдінга. Звідки йому знати наскільки порти ядра завантажені? Отож-бо.
Я ж кажу, технологія лютий костиль і давно не актуальна. Зараз тих транзисторів вже дівати нікуди. Проблема з ватами. Вати смт не зменшує, навіть навпаки. Натомість вносить купу проблем, починаючи з планувальника, і закінчуючи вимиванням л1 кешів.

Відправлено через 12 хвилин 35 секунд:
HT/SMT, до речі, не інтел вигадала. Її вигадали в ранніх рісках, альфах там і інших міпсах напочатку 90х, де ця технологія показувала себе шикарно в умовах тотального дефіциту транзисторів, більш ніж подвоюючи продуктивність ядра (бо практично всі юзали SMT4). В подальшому майже все ріски відмовились від SMT. Тому що кожній технології свій час.
Єдиний хто тягне досі smt4/8 це павер, але він радикально відрізняється архітектурно, і в ньому неможливий простій одного потока через блокування іншим, лише сповільнення. Звісно нічого безкоштовного не буває, і ціна тому є далеко не видатна однопоточна продуктивність цього самого павера. Вони вирішили що в їхньому профілі навантаження і так норм. Але це точно не десктопний випадок.