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

Обсуждение статей и новостей сайта
Автор
Сообщение
vmsolver
Member
Аватара пользователя

Сообщение

Scoffer: 24.02.2026 18:07У планувальника недостатньо інформації щоб правильно розпланувати потоки гіпертрейдінга. Звідки йому знати наскільки порти ядра завантажені? Отож-бо.
Планировщик знает сколько ядер свободно и занято, знает какие ядра являются одним ядром, поэтому нагружает по потоку на ядро, а если надо запустить больше, тогда запускают второй поток ядра если все ядра уже имеют по одному потоку. Причем оба потока одинаковы, можно запустить или первый, или второй, выполняться будет одинаково, эффект запуска второго потока также будет одинаков, так что всё планировщик знает.

А эффект при Аль-табе может быть вообще не связан с НТ, а реализацией одной из подсистем ОС, драйверов видеокарты, состоянием твоей конкретной системы и т.п.
Scoffer
Member
Аватара пользователя

Сообщение

vmsolver: 24.02.2026 18:23Планировщик знает
Нічого він не знає. Він бачить що головний поток юзає 10% проца, а вториний простоює. Значить на вториний можна підкинути завдання. А в реальності виявляється що не можна бо потоки побились оці самі 10% і інші 90 їм не треба в даний момент часу. Цей ефект постійно спостерігається на смт системах з самого народження смт. І якщо раніше з ним мирились бо не було інших путніх варіантів як розширити пропускну спроможність системи, то зараз це нафіг не потрібно. Ядра вже і половини чипу не займають, тепер там кеші всих рівнів і всякий інший анкор, котрі не зменшити доутилізувавши алу. Навпаки вигідніше рознести в просторі щоб не так сильно грілось і не вимивало сильно обмежені в ємності л1 даними з різних потоків. Та і л2 також.
Piter Cantrope
Member
Аватара пользователя
Откуда: Калуш

Сообщение

vmsolver: 24.02.2026 18:23 Планировщик знает
Він нічого не знає і ніколи не знав. Знати може "планувальник" на маках з Apple silicon, бо там один виробник ОС і заліза. І більш компетентна команда.
А на пк так нема, і не буде.
Планувальник тупить з райзенами, тупить з алдерами-рапторами і їх p- i e-ядрами, тупив з hyperthreading (нагадаю, що найшвидшими процами були 2500k i 3570k, допоки Інтел це не зрозумів і не почав їх обрізати по частоті, щоб була менша ніж в i7), і тупив з бульдозерами. Був простий спосіб отримати дуже великий приріст на бульдозерах: виставити пріоритет на ядра #0, 2, 4, 6. Це в деяких задачах давало величезний приріст. Величезний. Але планувальник нічого про це не знав.
Вінда ніколи нормально не працювала з більш ніж 1-м ядром. Ніколи. І ніколи не буде. Особливо тепер, коли такий зоопарк процесорів різних архітектур.
Klon
CG graphikos fan
Аватара пользователя
Откуда: Украина

Сообщение

хм, так і не побачив того чого я хотів від ціх ядер = енергоефективності в офісному використанні...
Наприклад запускаешь ютубчик\ворд і проц споживае пару ваттів , хай би працювало не швидко , но аккум би не вижирало....

А вийшло що в ноутах (що я бачив) інтели з міні ядрами стали жерти більше чем класична система Райзенов 4ххх + . Або так казалось...

Ну тут ще Вінда з індусами вайб-Аі кодерами , так що зовсім не зрозуміло де залізо пашет як надо в мінімумі :insane:
VladimirV
Member
Аватара пользователя

Сообщение

Piter Cantrope: 24.02.2026 21:27 тупив з hyperthreading (нагадаю, що найшвидшими процами були 2500k i 3570k, допоки Інтел це не зрозумів і не почав їх обрізати по частоті, щоб була менша ніж в i7)
Це що за тейк такий?
Як можна обрізати по частоті проци з буквою К? Бери, став множник який хочеш, розганяй свої 4 ядра без трейдингу, скільки в тебе витягне кремній. Не розумію. Хто цього не дає і чим обмежили? 57x Max Multiplier у нього.
Були в мене і 2500К і 3770К і 1270v2, на всіх i7 Sandy/Ivy де 4С/8Т, коли підкидав їм в пару rtx3060 і ddr3 2200+MT/s, бачив в іграх загрузку ядер/потоків на 100% всіх восьми. То в чому планувальник не справлявся?
vmsolver
Member
Аватара пользователя

Сообщение

Scoffer: 24.02.2026 21:19 Нічого він не знає. Він бачить що головний поток юзає 10% проца, а вториний простоює. Значить на вториний можна підкинути завдання. А в реальності виявляється що не можна бо потоки побились оці самі 10% і інші 90 їм не треба в даний момент часу. Цей ефект постійно спостерігається на смт системах з самого народження смт. І якщо раніше з ним мирились бо не було інших путніх варіантів як розширити пропускну спроможність системи, то зараз це нафіг не потрібно. Ядра вже і половини чипу не займають, тепер там кеші всих рівнів і всякий інший анкор, котрі не зменшити доутилізувавши алу. Навпаки вигідніше рознести в просторі щоб не так сильно грілось і не вимивало сильно обмежені в ємності л1 даними з різних потоків. Та і л2 також.
Нет у ядра главного потока, я же выше написал буквально это, оба виртуальных потока ядра абсолютно одинаковые, можно занимать любой один из них, а когда все ядра будут заняты уже запускать второй.
Пример слишком абстрактный, мол "ехал тракторист ехал и свернул налево, поэтому всё сломалось". Проценты это сколько времени ядро имеет запущенный поток. Что значит "побились об поток"? Что за гуманитарщина :facepalm:

Эффект SMT, это был один поток со скоростью 1, а стало 2 но со скоростями 0.55-0.8, что вместе даёт 1.1-1.4. Вот и весь эффект.

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

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

Відправлено через 4 хвилини 44 секунди:
Piter Cantrope: 24.02.2026 21:27
vmsolver: 24.02.2026 18:23 Планировщик знает
Він нічого не знає і ніколи не знав. Знати може "планувальник" на маках з Apple silicon, бо там один виробник ОС і заліза. І більш компетентна команда.
А на пк так нема, і не буде.
...
Особенности SMT планировщик знает, не выдумывайте, с эффектом SMT и сочетаниями программ столкнулись сразу и "базу" планировщику объяснили очень давно, но он не всегда может корректно работать с сочетаниями программ, просто программ много, а сочетаний ещё больше. Тут больше претензии к разработчикам программ, а не к процу, что он может и как - написано в документации. Винить в этом смысле SMT, а не программы - странно. Софт должен подстраиваться к железу, а не наоборот. Что в микрокоде возможно предпринять наверняка давно сделано.
Scoffer
Member
Аватара пользователя

Сообщение

vmsolver
Якщо чесно, то мені вже набридло тобі все пояснювати. Перечитай ще стільки раз поки не дійде. Операцію ділення я недаремно приплів як приклад, вона на все ядро рівно одна, не конвеєризується, займає 20-30 тактів, і чхати хотіла на кількість потоків. Якщо обидва потоки вимагають ділення, то все, приплили, це ботлнек. Таких операцій на х86 валом.
А ще є цілий розділ бар'єрів пам'яті, котрий блочить порти обміну з кешем теж незважаючи на другий потік, і вже на сотні тактів. І планувальник жодним чином не відстежує потоки команд щоб розкидувати їх по потокам ядра чи іншим ядрам, щоб вони не блочили там один і той самий порт в одному і тому самому ядрі. Не відстежував, не відстежує, і відстежувати не буде, ніколи.
yurius_r
Member

Сообщение

Scoffer: 24.02.2026 18:07У планувальника недостатньо інформації щоб правильно розпланувати потоки гіпертрейдінга
Якби така проблема глобально існувала, її б вирішили. Питання із маленькими та великими ядрами ж якось вирішуть.
HT/SMT, до речі, не інтел вигадала
Головне реалізація. А SMT4 був і в інтела, все хочу вяти погратися Xeon Phi x200, але немає часу
Scoffer
Member
Аватара пользователя

Сообщение

yurius_r: 24.02.2026 23:56Якби така проблема глобально існувала, її б вирішили.
Її і вирішили наклепавши недоядра. Проблема зникла повністю, під нуль. Хочу зауважити що та ж апле теж принципово не робить ніяких гіпертрейдингів, а сидить на недоядрах. Як і квалком, як і медіатек, як і серверні арми від амазона і ажура, як і багато інших, хоча смт технологія дуже примітивна, її осилили ще напочатку 90х. На х86 воно чисто по інерції, і гарантовано буде випилено також у амд. Такий шлях.
vmsolver
Member
Аватара пользователя

Сообщение

Scoffer: 24.02.2026 22:56 Якщо чесно, то мені вже набридло тобі все пояснювати. Перечитай ще стільки раз поки не дійде. Операцію ділення я недаремно приплів як приклад, вона на все ядро рівно одна, не конвеєризується, займає 20-30 тактів, і чхати хотіла на кількість потоків. Якщо обидва потоки вимагають ділення, то все, приплили, це ботлнек. Таких операцій на х86 валом.
А ще є цілий розділ бар'єрів пам'яті, котрий блочить порти обміну з кешем теж незважаючи на другий потік, і вже на сотні тактів. І планувальник жодним чином не відстежує потоки команд щоб розкидувати їх по потокам ядра чи іншим ядрам, щоб вони не блочили там один і той самий порт в одному і тому самому ядрі. Не відстежував, не відстежує, і відстежувати не буде, ніколи.
Сейчас все процессоры довольно широкие и такого упора уже нет. Но в общей картине, тебе не кажется странным ругать инструмент доутилизации простаивающих мощностей? Всё как я и сказал ранее, это не проблема проца, это проблема софта, софт должен подстраиваться под железо.

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

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

Итого, все найденные тобой "недостатки" просто обратная медаль достоинств подхода, нет ничего идеального в подходе доутилизации неидеальной загрузки исполнительных портов. Софт должен подстраиваться, а не хард, не устаю повторять.
yurius_r
Member

Сообщение

Scoffer: 25.02.2026 00:00Її і вирішили наклепавши недоядра
Та ніфіга її не вирішили. Ті самі проблеми із планувальниками і роботою додатків у таких процах із різними ядрами у 2026. Погляньте на тести ігор. Почитайте як там VMWare Workstation страждає. Ну і той самий Інтел у великих Xeon ядра не мішає чомусь
s1nedus
Member

Сообщение

1234waltz: 24.02.2026 11:44
alexeygalas: 24.02.2026 10:54
Як раз таки показала, що дуже добре компенсує навіть з наваром і HT не потрібен.
Лол
спойлер
В цих бенчах в 14900к була зі звичайною DDR5-7200 за 120 баксів (на момент написання статті), а в 285K CUDIMM DDR5-8200 за 200 баксів (який нахоботила редакція, але вказали, що загалом тоді вони коштували 300). Дуже добре себе демонструє, при сумарній ціні платформи (на момент написання) майже в двічі дорожчої, з урахуванням самого проца та материнки.
Изображение
Изображение
Изображение
Проблемы ультры в играх не от разных ядер, HT
А онли от увеличения межядерной задержки и латентности. Рабочие задачи идут отлично, тем более если учитывать низкое энергопотребление. Игровую проблему обещали решить в nova lake. А с учётом что поднимут жер, который был задушен, надеюсь выйдут нормальные процы которые отлично покажут себя в играх. Конкуренция нужна всем
alexeygalas
Member
Аватара пользователя
Откуда: Khmelnytskyi

Сообщение

Piter Cantrope: 24.02.2026 21:27Він нічого не знає і ніколи не знав. Знати може "планувальник" на маках з Apple silicon,
На intel теж знав. Поки у мене була прошка 2019 на i9-9880hk, я на останніх версіях ос чітко слідкував, чи не забили вони ще на інтел. І там чітко були навантажені непарні потоки тобто фізичні ядра. Коли їх бракувало - починали задіюватись парні.
DuckRider
Member
Аватара пользователя

Сообщение

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

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

Сообщение

Ну якби для робочих задач топовий процесор потрібен одиницям а для ігор як показали продажі амд топовий процесор потрібен усім, пихати в десктоп енергоефективність це повна маячня і це було зрозуміло одразу на релізі 12 покоління. В ноутбуках клєпайте шо вам хочеться. Чи зможуть нові проци інтел знову в ігри побачим, бо якщо не зможуть то компанії гайки.
1234waltz
Member

Сообщение

Piter Cantrope: 24.02.2026 21:27 Він нічого не знає і ніколи не знав.
Знає і давно.

Пояснюю на пальцях, в ведрі Лінукс є така штука як ієрархічна система розподілення навантаження.
Ядро знає де є:
Логічні потоки на одному ядрі.
Фізичне ядро на одному кристалі/кластері.
Кількість кластерів.
Кількість фізичних ЦПУ та NUMA топологію.
Відповідно процеси розкидуються і в процесах на одному фізичному ядрі, але двух потока, навіть спеціальний флаг є для таких процесів (що логічно).

Щодо Шиндоушс. В ньому НЕОУЧІУВАННО теж все є і все він вміє. Просто реалізовано трошки інакше.
1. Планувальник знає та розрізняє всю топологію процессора, як в і Лінукс.
2. Є черговість та система уникнення конфліктів.
3. Працює принцип - спочатку використовувати "фізичне ядро" зі 100% навантаженням.
4. Планувальник Віндоус навіть знає та вміє кидати споріднені процеси на один конкретний CCX в Zen архітектурі. Умовно важкий софт, типу гри, якщо йому вистачить ядер та потоків буде кидатись на один фізичний CCX. Так, на релізі перших Тредріперів та Зенів АМД обісрались і не встигли Майкрософту софтверну підтримку, все це виправили к середині житття Зен 2, але то вже інша історія)).

Оскільки Шиндоушс пропрієтарна, по ній інфи менше. Але. Казати, що планувальники ОС сучасних щось не бачать і не вміють це дикуха люта.
Наприклад Hyper-V, колись там дійсно був прикол (як і в інших віртуалках) з віддачею одного куска ядра з smt на дві віртуалки. Але вже досить давно ВМці там віддається фізичне ядро, логічні потоки якого можуть ділитить тільки в межах конкретної ВМки віртуалки.

Тому про які печерні роки ви пишете, взагалі дивина.
Scoffer
Member
Аватара пользователя

Сообщение

1234waltz: 25.02.2026 10:28Знає і давно.
Не знає. Ти міряєш ядро як якоюсь монолітною сутністю, а це ніфіга не так. В сучасних ядрах доходить до 10 паралельних черг виконання, кожна з котрих вміє робити лише частину роботи. Так от планувальник не в курсі як їх завантажувати, і взагалі це не його робота, він і не має бути в курсі. Тим не менш вони впливають на смт потоки.
vmsolver: 25.02.2026 00:08А ты не задумывался, почему аппаратный делитель, раз ты его приводишь в пример, один? Давно же можно было расширить, пару миллионов транзисторов туда или сюда не повлияют на что-либо.
Саме так і зроблено в ібм павер. Там в ядрі 8 так званих execution slice'ів, кожен з котрих вміє виконувати всі команди, і логічні, і арифметичні, і бранчі, і навіть завантаження-збереження. Як наслідок багатопоточна продуктивність ядра страшна, в 2.5-3 рази більша за х86 аналоги. А однопоточна недотягує навіть до недоядер. Бо чудес не буває, і за все треба платити. От тому на х86 так і не роблять. Не їхній профіль навантаження. Людь не зрозуміє куди дівся їх фпс в ігрулях.
yurius_r: 25.02.2026 00:13Почитайте як там VMWare Workstation страждає.
Враховуючи скільки власників змінила вмварь за останні роки, і те що на воркстейшни офіційно покладений болт, то дивно що там взагалі хоч щось працює :laugh:
1234waltz
Member

Сообщение

Scoffer: 25.02.2026 10:40 В сучасних ядрах доходить до 10 паралельних черг виконання, кожна з котрих вміє робити лише частину роботи. Так от планувальник не в курсі як їх завантажувати, і взагалі це не його робота, він і не має бути в курсі.
Саме тому в Лінукс ядрі є оцінка активності кожного процесу, де у ядра та smt присвоюються різні пропускні здатності і важкі задачі кидаються на "ядро", а легкі на два логічних потоки. І балансування навантаження працює тому, що там таймер планувальника в мікросекундах оцінє тривалість задачі і якщо вона стає "заважкою" для логічного потока буде перекидувати її на вільне "ядро" (якщо таке є). Тому планувальник буквально знає, що куди кидати, по по процесам ще й історія ведеться.

Ну блін, у smt звісно є певні мінуси. Але розповідати, що планувальник щось не вміє, коли в АРМ процесорах може бути зоопарк з 4 різнорізних кластерів (як в Ексіносах свіжих та деяких Снепах), і якось планувальник справляється з цим парадом лайна і додатково використовується прорахунок вартості пробудження кластерів та ядер в мВатт. Ця фігня рахується планувальником підтягуючи данні взагалі індивідуально з фірмавірі кожного пристроя індвідуально, наприклад.
Scoffer
Member
Аватара пользователя

Сообщение

1234waltz
Я зараз вже матом розмовляти почну. Ти теж перечитуй що я написав поки не дійде. SMT ні разу не аналог кластерів з недоядрами. З недоядрами ніяких проблем не існує. Просто береш і розкидуєш завдання в порядку приорітету. Примітивний і дієвий алгоритм. З SMT проблема в тому що потоки SMT напряму впливають один на одного і планувальник не може передбачити як саме. Не може і все тут. Не володіє він цією інфою. Змирись з цим фактом.
І от щоб не розбиратись якого ж біса все в черговий раз пішло не так, більшість процесорів зараз не мають смт, хоча колись давно все було з точністю до навпаки, того смт не робив лише ледачий (читати як амд), навіть в мобільниках було. І сплило.
1234waltz
Member

Сообщение

Scoffer: 25.02.2026 11:04 Я зараз вже матом розмовляти почну.
Якщо "блін" та "парад лайна" відносно 4 кластерного зоопарку Ексіносів то мати, то я навіть не знаю :)
Ответить