Новые процессоры 2026 года от intel и зоопарк ядер (P-ядра,E-ядра,LP-E-ядра)

Для мобильного устройства (P-ядра,E-ядра,LP-E-ядра) возможно хорошо.

Но не как не пойму, для чего городить весь этот зоопарк ядер на стационарном железе, где не от батарейки работается.

не как не пойму, для чего городить весь этот зоопарк ядер на стационарном железе

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

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

И вот я сам не знаю, хорошо ли он работает. Как-то работает, а как понять - хорошо или нет, я так и не понял. Мне показалось, что он просто кидает задачи на P ядро, когда P ядра кончаются - дальше кидает на E ядра, ну т.е. алгоритм максимально примитивный и неэнергоэффективный. Для работы от розетки оптимально, а для работы от батареи - наверное не очень оптимально.

В макоси приложения сами помечают потоки, которым не требуется производительность (например проверка почты по таймеру), и ОС эти потоки всегда кидает на E ядра. Что даёт возможность процессору работать в очень энергоэффективном режиме большую часть времени, в то же время выполняя необходимые фоновые задачи. Но в линуксе такого API нет и приложения максимум могут через аналог cpuset прибить поток к нужным ядрам (наверное, я сам не пробовал), но, конечно, делать это они не будут.

В винде есть некий компонент от Intel под названием Thread Director, который вроде как анализирует деятельность потоков и тд и как-то «интеллектуально» раскладывает потоки по ядрам, видимо предсказывая то, насколько потоку важна производительность. Возможно даже процессор сам помогает с этими решениями, а код от Intel просто взаимодействует с ним. В линуксе что-то подобное тоже гуглится, но очень невнятно.

В макоси приложения сами помечают потоки, которым не требуется производительность (например проверка почты по таймеру), и ОС эти потоки всегда кидает на E ядра. Что даёт возможность процессору работать в очень энергоэффективном режиме большую часть времени, в то же время выполняя необходимые фоновые задачи. Но в линуксе такого API нет и приложения максимум могут через аналог cpuset прибить поток к нужным ядрам (наверное, я сам не пробовал), но, конечно, делать это они не будут.

Интересно. Может быть стоит такое в Haiku добавить.

Наверное есть люди, которым важно потребление стационарных ПК. А вообще у меня складывается впечатление, что тепловой бюджет выбирается быстро, а по транзисторам ещё остаётся большой запас. И в процессор уже суют что попало, т.к. место на кристалле есть, маркетинг это продаст. Типа есть 10 быстрых ядер и больше уже смысла нет сувать, т.к. и 10 уже в предел влезают по потреблению и охлаждению. Но можно ещё какой-нибудь NPU добавить, который будет матрицы перемножать чуть энергоэффективней и блюрить фон в скайпе, а маркетинг это уже продаст, как AI-ENABLED HYBRID PROCESSOR TECHNOLOGY.

То же с энергоэффективными ядрами.

Лично я бы себе вообще не покупал всё это, мне нужны обычные ядра, даже без HT. А всё остальное не нужно. Но у Intel таких процессоров уже не осталось совсем (разве что в BIOS отключить лишние ядра, но, например, на моём ноутбуке такой опции тупо нет). У AMD вроде ещё недавно были, но пока я не доверяю AMD.

Я не совсем понял, к кому этот текст был адресован? Уверен, что вы совсем не по адресу.

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

горячие ядра перемежают более холодными

Ну лол же, они ведь в кластерах. )
Во время alder lake кластер из 4х E-ядер занимал ~x1.25 площади большого ядра и каждое из них было ~ в 60% по производительности. Это просто более выгодная трата кремния и потребления в расчёте на общую многопоточную производительность.

Наверное есть люди, которым важно потребление стационарных ПК

А вообще у меня складывается впечатление, что тепловой бюджет выбирается быстро, а по транзисторам ещё остаётся большой запас

То есть в голове вообще не стреляет, что вот это вот оно между собой связано? Оказывается, чтобы получить производительность надо обратить внимание на тепловыделение = потребление

горячие ядра перемежают более холодными

Потому что если горячих ядер >6, тогда они начинают перегреваться и троллить/сгорать. И отвести тепло от них не получается. А если снижать частоту, тогда они начинают превращаться в тыкву и не могут составить конкуренцию амд. Всё по причине того, что интел десятилетиями не вкладывалась в архитектуру и зарабатывала бабло, которое пилило. Именно по этой причине начали миксовать ядра

У амд они тоже перегреваются, тротлят и снижают частоты

У амд они тоже перегреваются, тротлят и снижают частоты

Тогда троллить/сгорать –> сгорать. Скорей всего при компоновке >6 они тупо сгорали, поэтому в панике было принято решение о E-ядрах. Завуалировали это «энергосбережением» и прочей фигнёй

Это чистая ложь. Даже разогнанный зион W-серии(а там до 52х ядер), который жрёт больше двух киловатт, успешно охлаждают.

Щас тебе расскажут про сгорающие рапторлейки

Может зион на другом техпроцессе. А на техпроцессе новых камней или деградация идет или дохнут. Очень странно, что больше 6 Р ядер на камне не ставят

Почему больше 6P ядер не ставят? А как же Intel Core Ultra 9 285 8P ядер.

А на техпроцессе новых камней или деградация идет или дохнут.

Каком конкретно техпроцессе? Дохли рапторы, а это уже пожилые процы. Ни на Arrow lake, ни на Lunar lake жалоб я не видел.

Потому что поняли что это будет слишком жирно. Если андервольт провести, то 8 ядер будут в сумме быстрее 6-ти ядер, но при этом могут потреблять намного меньше. P ядра рулят абсолютно и бесповоротно, тем более в линуксе когда ты ставишь максимальный приоритет процесса, тогда если что и падает на малые ядра, то всякая чушь типа звука может быть пара процентов. Причем если планировщик показывает тебе тупо 40% загрузки по этим малым ядрам это не значит что они нагружены. Это заняты, мол, ждем данные, а вдруг будут. На деле могут быть 0-2% работы этих ядер при 40% показываемой занятости. Тут только по потреблению выявлять где мониторинг нашкодил. Я уже давал ссылку на игоря с UE5 и там ясно видно что потребление в играх низкое. Этих 6 P ядер может и хватит, а вот кеша общего может не хватать постоянно. Тем более с отрезанным гипер тридингом. Тем более на мобильной платформе без возможности андервольта. Тем более на битой архитектуре с лютым добавочным лагом при обращении к памяти. Тем более когда нельзя нарулить Gear 1 в настройках памяти DDR5. Там все отрезано по сути. Ненужно ждать от мобильного процессора прыти. Они попытались выпустить печки, но цены загнули. Они бы цену сбавили раза в два, тогда был бы спрос. Так что сейчас выгоднее брать топовые процессоры с 8 P ядрами на борту. Они по любому будут в играх рулить. Все остальное прогнозам не поддается. Для сравнения 12900K топ - 8 P ядер, 13600K середнячок с 6-ю P ядрами. Это сразу резко сдвигает процессор ниже, потому что мелкие ядра не замена быстрым, но 6 ядер вполне сносно смотрятся в мобильном сегменте, если вместо чего-то стоящего совать вот это недоразумение с отрезанной третью потенциала - для шести ядер 2 это ровно треть. E ядра это для программ, анальных зондов, мусора всякого. Совсем E ядра это типа «Ну чё там? Связь есть? А ну, ну понятно, я пока посплю». Встроили ядра грубо говоря 15-летней давности на новом техпроцессе. Прогресс типа. Стоит дороже в разы только лучшее, а это лучшее только на десктопе у интелов - вот такие трюки маркетинга. А подобные процессоры это развод лохов.

Дохли 13-е и 14-е поколения потому что обывателям не объясняли что при запуске компа там могут идти дикие токи в базовом то режиме, а они после включения разгона лупят процессор еще большими токами под совсем зашкаливающим напряжением. Процессоры ни разу не устарели ввиду провальной платформы для игр. Играм с большим избытком 12-го поколения без разгона. Пожилые у тебя мозги. Те у кого они имеются сразу делают андервольт, но боюсь таких людей крайне мало. ты производительность десктопного камня сравниваешь в вакууме с мобильной фиговинкой. Очнись уже. Для какого-нибудь Geekbench 6 крайне важна производительность памяти. Эти новые интелы протолкали благодаря в щи разогнанной новой памяти, но это бестолковый вариант для интерактивных приложений типа игр. Их еще производят болезный и до следующего года поставлять будут.

Новые процессоры 2026 года от intel и зоопарк ядер (P-ядра,E-ядра,LP-E-ядра) (комментарий)

Почему больше 6P ядер не ставят? А как же Intel Core Ultra 9 285 8P ядер

Я думаю, что это отборные образцы по литографии. Чем лучше литография, тем ниже тепловыделение

Каком конкретно техпроцессе? Дохли рапторы, а это уже пожилые процы. Ни на Arrow lake, ни на Lunar lake жалоб я не видел.

Еще раз, в новых камнях почему все Р ядра не ставили? Потому что ядра такие горячие, что если их больше 6 штук ставить - то проблематично отвести тепло и они то ли троллили, то ли деградировали, то ли дохли. Именно по этой причине интел сделала гибридную РЕ архитектуру, навешав лапши юзерам о том, что это революция

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

Новые процессоры 2026 года от intel и зоопарк ядер (P-ядра,E-ядра,LP-E-ядра) (комментарий)

а как это деления ядер (P-ядра,E-ядра,LP-E-ядра) сказывается на ядре линукс?

Гибридная архитектура Intel уже готова для Linux? (комментарий)

Да почти никак, архитектура у них одинаковая(за исключением первых Alder lake, где на ранних БИОСах была поддержка AVX512 на больших ядрах). Поэтому работать будет и так, главные вопросы только к планировщикам, куда раскидывать процессы.
А уж разных планировщиков в ядре хоть жопой жуй. Даже по звёздам )
https://github.com/zampierilucas/scx_horoscope

Ссылка годная, но это состояние год назад

For a given library of CMOS logic, active power increases as the logic switches more per second, while leakage increases with the number of transistors. When a very fast out-of-order CPU is idling at very low speeds, a CPU with much less leakage (fewer transistors) could do the same work.

Во как интересно всё. Сложное и быстрое ядро даже без загрузки, на низкой частоте, создаёт большой ток утечки, потому что в нём банально много транзисторов.

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

Никак, потому что вопрос некорректный. Линукс уже давно работает на гибридных архитектурах, потому что Андроид версии там что-то вроде 4.4 научился этому. Линукс не винда, которая с трудом работает с большим числом потоков. Поэтому интелы на линуксе быстрее могут быть и запросто может получиться ситуация что не новый интел обгонит 9800x3d в играх. Тут от кривизны кода игры зависит, но само ядро и планировщик работают эффективнее, но обычно распространяют ложную информацию. И это цифры уже после трансляции виндового кода в линуксовый через Wine/Proton, то есть эти 15% далеко не обязательно предел разницы платформ. Вот тут как пример чувак в Cyberpunk 2077 на 13900К объясняет что на линуксе все сильно круче, чем на винде, которой требуется включение генерации кадров на RTX 4090. Если бы он оптимизировал опции запуска с высоким приоритетом, плюс полная настройка железа, то могло быть и получше.

https://www.youtube.com/watch?v=sxGDSNmiEKg

So just keep in mind that on Ubuntu 24.04, Cyberpunk 2077 got 60 FPS to 65 FPS Average, without Frame Generation and without DLSS 3.5, while on Windows, with Frame Generation and the more optimized DLSS 3.5, Windows users are getting around 70 FPS to 75 FPS (10 FPS).

Ну да, в винде и без андервольта у меня процессор около 15 ватт жрал в простое. В линуксе это 3-3,5 ватта, при проигрывании видео до 4,3 ватт. Офигеть цифры конечно. Интеловцы просто рассчитывают на тупых американцев как потребителей. Сказали вот, дофига крутой нужен блок питания - они послушно пойдут и возьмут на киловатт, хотя хватило бы 400 ватт честных например. А эти ARM это для лютого мега экономного расходования заряда. Там разница небольшая будет для ноутбуков и пока ноутбуки на армах нифига не лучше Lunar Lake. Как только надо что-то делать, хотя бы неспешно они жрут больше. Плюс линукс там криво работает. Ребята ARM это для лютых чудиков пока что.

Чтобы показывать оптимальную производительность и автономность хорошо бы уметь планировать размещение процессов с учётом особенностей этих видов ядер. А так то приложения запускаются

Если предыдущее это Core Ultra 1**, а нынешнее Core Ultra 2** - то все там нормально. Если конечно ACPI прямыми руками сделан.

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

а как это деления ядер (P-ядра,E-ядра,LP-E-ядра) сказывается на ядре линукс?

Архитектурно никак. Вес эти ядра имеют один и тот же набор инструкций, просто реализуют их с разной эффективностью. Какие процессы попали на быстрые ядра - работают быстрее, какие на медленные - ну… Медленнее. То есть например 2xP-ядра туда-сюда примерно как 4ъЕ-ядра, а на LP-ядрах вообще ад содом и лютые тормоза (ибо у них ЕМНИП нет доступа к кэшу L3)

Не, нынешнее это уже неделю как core ultra 3** оно же panther lake

А в чем затея? Парковка конкретных групп ядер? Это на каком железе?

В пантерлейке как раз ускорили lpe ядра и сделали их 4, а не два. С отдельным L3 там так же тухло, но есть некая замена

Хмм, допустим задача обновления мира системы в gentoo? Как планировщик поймет, что скачка исходника и компиляция этого самого исходника, чистка временных файлов после установки этого исходника, это 3ри разные по весу выполения задачи?

А так же из crontab по расписанию задачи, есть же ресурсо емкие задачи, а есть чисто отправить письмо по расписанию.

У вас какой-то негодный пример, в котором процессы запускаются последовательно. То есть планировщику не над чем «думать».

В целом классифицировать задачи можно разными способами и по ресурсоемкости может быть не самый оптимальный. Например фоновое сканирование файловой системы на вирусы, оно ресурсоемкое, но на скорость его выполнения вам скорее всего наплевать, закончится оно на пол часа раньше или на пол часа позже. А вот если вы запустили почтовый клиент, то про новые письма вы возможно хотите узнать как можно скорее. А может и нет. Может вы запустили клиент чтобы отправить письмо. И пока вы наберёте текст письма, клиент даже на самом дохлом ядре процессора успеет получить новые письма с сервера и показать их в списке

Смысл в том, чтобы исключить из работы некоторые кластеры целиком, типа если я знаю что мне хватает 4 потоков, я бы их все запарковал в один кластер а остальные тупо исключил из шедулинга, после чего они могут отправиться в беспробудную спячку. Или наоборот - если у меня нет активно жрущих задач, то можно например скинуть все на пару E-ядер а обработку прерываний на LPe вообще.

Как планировщик поймет

А никак, в этом-то и проблема, что никакой информации о процессах у него изначально нет, и он может только собирать статистику, кто/как часто/как много жрёт процессорного времени. Всё более интеллектуальное - непаханое поле в том числе и на винде. Над алгоритмами Thread Director кто только ни угорал. Можно конечно писать профили под каждую программу, куда и на каких условиях девать её треды, но этим что-то кажется никто так и не озаботился.

в беспробудную спячку

Там ещё и в соседний кэш лазить дорого, потому оно ещё и вопрос производительности.