В теме в полной мере действуют >>> ПРАВИЛА КОНФЕРЕНЦИИ

Смежные темы, где можно задать или обсудить свои вопросы, не касающиеся или косвенно касающиеся процессоров Arrow Lake-S

1. Температура процессоров Intel (FAQ - стр.1)
2. FAQ: Какой процессор будет оптимальным для моих задач? (часть 2)
3. Методика тестирования и определение стабильности при разгоне процессоров Intel
4. Производительность системы в гигафлопсах? (Linpack / IBT / LinX / etc.)
5. Всё о скальпировании процессоров...
6. Выбор воздушного кулера для процессора - скорая помощь новичкам и бывалым + FAQ (часть 2)
7. СЖО. Выбор необслуживаемых систем (AIO)
8. Статистика разгона памяти DDR-5 на платформах Intel

✔️ Новый сокет LGA 1851 (совместимость с охлаждением под LGA 1700 сохраняется, однако центр точки нагрева у новых процессоров несколько смещен, в связи с чем производители систем охлаждения готовят адаптированные под новый сокет крепления). Разница незначительна, но может быть полезным при чрезмерном нагреве.
✔️ Процессоры сохранят гибридный набор ядер (Р+Е)
✔️ Впервые со времен LGA 775 у процессоров не будет HT (Hyper Threading)
✔️ Увеличенное число линий PCI-E 5.0 для процессора (теперь их 20 - на 4 больше, чем у предшественников)
✔️ Процессоры этой серии будут совместимы только с памятью стандарта DDR5
✔️ Новое графическое ядро Xe
✔️ Новые чипсеты - Z890/H870/B860/H810










Гайды для настройки процессоров Arrow Lake:
https://skatterbencher.com/
Overclock.net

Раздел будет дополняться по мере поступления новой информации

Vitaly1988
У меня NGU и D2D стабильно работают на множителе 33
SA Voltage: 1.15
VNNANON Voltage: 0.83
VDD2 Voltage: 1.19
IO Voltage: 1.06

О, они это могут. 1.72v на ядра долго висело.

Ой как смешно. Можешь проверить, там и сейчас "висит". Сюрприз, но никакого физического смысла нет и никогда не было что у 1.52V лимита до 12 поколения, что у 1.72V после. Сколько можно эту откровенную глупость друг за другом повторять и самому над "очень смешной шуткой" же и смеяться?

Это значение напряжения, которое в принципе возможно закодировать (1.52V + 200mV смещение) в рамках используемого VRM протокола, а не значение, которое можно безопасно ставить или что там себе воображаете. Это значит, что процессор может у VRM попросить это значение выдать и VRM его поймет. Большее значение в доступные для кодирования биты элементарно не влезет, вот и "лимит". Уже ясно, или всё ещё смешно?

P.S. Кстати, для попугайчиков, на 1851 сокете максимальное значение офсета теперь 250 mV, так что "лимит" теперь 1.77V (то есть 1.52 + 250mV).



Можете бежать в биос ставить и смеяться, клоуны. Ха-ха. Ну давай посмейся, шпицыолизд.

Intel Ultra 5 245K vs Ultra 7 265K vs Ultra 9 285K // Test in 8 Games

А я не только про Интел. У АМД по слухам тоже будет 12 ядер чиплет. Да и по Интел обнадёживающие новости появляются. На днях 12 ядерник всплыл на слайде Интел.

А вот таблица с инфой по утечкам.

Кстати по утечкам в Nova Lake вернётся AVX512, а точнее даже его чуть улучшенная версия AVX10.2 и новые APX инструкции которые ускоряют производительность.

Так на момент выхода это была лучшая архитектура и топовый проц. О чём ты вообще?
А после него вышел 8 ядерный 11900К который на новой непереименованной архитектуре и благополучно ему слил в то время как 10900К продолжал рвать уже новую ряженку 5000

Начиная с 11 поколения Интел стал чудить, потому что надо было догонять 3950Х и 5950Х по попугаям. Сначала уменьшил число ядер, а потом накидал кукурузы.


Прогнать тест со всеми ядрами, выключить в биос E-ядра. Прогнать на P ядрах. Вычесть из первого второе.
В играх можно отрубать P-ядра пока 1 не останется и смотреть как это на фпс влияет. А можно снизить P ядрам частоты чтобы производительность в CPU-Z была на уровне E-ядер. Тогда можно сравнивать архитектуру.

Ну сдай его в музей тогда.
Он что-то мог только потому что AMD тогда еще только догоняла, промчались мимо они чуток позже. Но именно политика выпуска одного и того же каждый год привела интел к тому, что есть. Если прогнать на 10 поколении любой имеющий хоть какую-то практическую пользу тест, и не выигрывающий только за счет ddr4, то внезапно обнаружится, что ядра на mhz там равны 4 поколению. 7 лет одного и того же.
Сейчас он немощный старик. A Golden Cove еще бодрячком даже в 6P-версиях. Не говоря уже про Lion.

10700k? Ну да, целых 20% сливает новейшему 265к в играх в 720p.
Если конечно верить techpowerup.

Я и не утверждал что он сейчас тащит

В таком случае ничего не поменялось. 12-13-14-200 будут примерно равны на одной частоте в играх + рефреш Стелозёров, вот 5 лет и выйдет.
Тут выводы напрашиваются, что 10 старых ядер обгоняли 8 новых 11 поколения. На момент выхода 12 поколения они могли сделать опять 10 ядер, но маркетинг победил, надо было догонять чиплетных франкенштейнов от АМД в попугаях. Прошло 4 года, и оказалось что большинство покупателей ложили болт на попугаи, а хотят ФПС, поэтому готовы переплачивать за относительно слабые в многопотоке 8-ядерные Х3D. АМД сделали две линейки камней, 3D и обычные. А Интел только одну - универсальную. Думали самые умные и сэкономят, куча ядер - куча отбраковки под младшие камни. В итоге просрали столько бабок, что ничего не выиграли. Скупой платит дважды. Надо было им отдельно чисто игровой проц делать на 10, а потом 12 ядер - был бы топчик под тяжелые UE5 проекты. Выход 12 ядерников сейчас, доказательство, что проблем с этим не было. Я бы точно выбрал 10-12 синих ядер вместо любого Х3D камня.

Хватит линковать тесты видеокарт в теме про процессоры.

Фениксом и его экселем запахло. Это не метод.

возможно, поглядим осенью, меня они не интересуют жду Zen6 и Nova.

Именно такой метод я встречал в инете не раз. Если ты накинешь к примеру с помощью Process lasso на E-ядра нагрузку, у тебя куча системных процессов будет висеть на P ядрах всё равно, разгружая Е ядра. Поэтому я кстати думаю что тесты E-ядер в играх через Process lasso - туфта полная. Виндовые системные библиотеки, драйвера видюхи и directX библиотеки скорее всего как висели на P ядрах так и будут висеть. А буквально недавно было показано как Intel Arc B580 обходила конкурентов на свежих ЦП и резко сдувалась на слабых ЦП из-за значительной процессороной нагрузки её драйверов.
ЗЫ Может ParkControl тебе поможет https://bitsum.com/parkcontrol/


Zen6 думаю будет топчик (если АМД не зажмёт 12 ядерные чиплеты для серверов). А вот Nova это будет жесть если слухи подтвердятся, новый "король синебенча" сразу с двумя косяками, гибридной архитектурой и чиплетами. Получится что играть можно будет нормально как и на АМД только на одном чиплете.

Добавлено спустя 10 минут 37 секунд:
stockclock, при нормальном тестировании эта нагрузка от системы не превышает 1-2%. Херня полная, не стоящая внимания.

Факт в том что она, эта нагрузка есть, я именно про игры говорю, потому что синебенч практически никак виндовые компоненты и дрова не использует.
Выглядит это так. Кидаю игру на 4 последних ядра. Видим заметную нагрузку на первом ядре.

Вырубаем игру. Видим что нагрузка с первого ядра исчезает.

Это доказывает что тесты игр на E-ядрах всегда будут частично юзать P-ядра. А значит пользоваться всеми преимуществами архитектуры P-ядер.
Из-за того что отключать P-ядра полностью нельзя и перекидывать многие системные процессы на другие ядра запрещено, чистую производительность E-ядер в играх не увидеть никак. Можно только гадать как оно себя бы повело. Может средний фпс был бы близок, а скажем 1%/0.1% на чистых E-ядрах упал бы.

Если же считать что свежие Е-ядра не хуже P-ядер, просто по частотам ещё не тянут, то ждём когда в скором будущем Интел выкатит 32 E-ядерные камни Тут одни преимущества, максимальная энергоэффективность, максимальный многопоток в синебенчах, максимально эффективное использование площади кристалла, никаких проблем с планировщиком - ядра одинаковые.
Тем более в серверах Интел именно так и делает. Выпускает либо чистые P-ядерники либо чистые E-ядерники.

stockclock, это гибридный процессор. Для него нормально использование всех ядер одновременно, попытки этого избежать делают тестирование искусственным. Если хочешь процессор из Р-ядер, то отключи Е-ядра. Если хочешь процессор из Е-ядер, то купи Е-ядерный Зион или i3 305 какой-нибудь.

Добавлено спустя 4 минуты 28 секунд:
stockclock, они не хуже по теоретической производительности, но возможность реализации этой производительности на практике зависит и от качества кода. Е-ядра на кривом коде просядут сильнее, чем Р. Да-да, сейчас опять появится клоун и скажет, как он всех в игрульках победил, пропустим эту стадию.

Добавлено спустя 1 минуту 52 секунды:
stockclock, нагрузи P-ядра праймом smallest FFTs с повышенным приоритетом. Винда будет вынуждена использовать другие ядра, если Р будут полностью заняты. Получишь чистое тестирование Е-ядер. Потом зеркально, грузи уже Е-ядра праймом и тестируй игру на Р. И там и там будет дополнительная нагрузка в виде операций прайма с кэшем, но при одинаковом количестве потоков этот фактор в первом приближении можно исключить. На рапторах Р это 16 потоков и Е это тоже 16 потоков. На сабже придётся часть Е-ядер отключить, чтобы симметрично было.

Так нагрузку не только процесс игры даёт. У вас есть ещё драйвер видеокарты, операционная система, вспомогательные процессы игры, античит на уровне драйвера. Это другие процессы, но во время игры нагрузка идёт и на них.
Это к слову одна из причин почему я при большом количестве ядер и умеренной общей нагрузке рекомендую исключать "0" ядро и его второй поток, если есть. Это радикально проще чем пытаться стащить с 0 потока низкоуровневые вещи.
С 200S стало интреснее раскидывать нагрузку. Появилась часть нагрузки которая может быстрее выполняться на E-Ядрах.
Концепция выжимания максимума из "малопоточных" приложений в условиях большого количества ядер обычно сводится к общим для всех цп правил.
1. Освободить 0 Ядро и его второй поток если он есть. Это к слову может давать больше чем все остальные манипуляции вместе взятые.
2. Основная нагрузка должна быть в одном "кластере" ядер. Внутри одного сокета, одной ноды, одного CCX. Я вообще не представляю как можно играть на многосокетной системе без привязки к ноде, в отличие от чиплетных райзенов попадание "монолитной" нагрузки в разные сокеты вызывает реально радикальный провал.
3. Определить оптимальную конфигурацию для максимальной производительности, она внезапно может быть разной.
Варианты:
Производительные ядра, БЕЗ SMT\HT.
То же самое с SMT\HT
Эффективные ядра
Различные комбинации маловероятно будут эффективны, но это возможно.
4. Отправить фоновую и не очень нагрузку на свободные ядра.
Можно всё это пытаться делать не жёстким аффинити, а манипуляцией приоритетами потоков, но это сложнее и не всегда работает "со стороны".
Основная проблема это заставить "главный" поток висеть на конкретном ядре, никуда не прыгать, ничего другого на него не кидать.

Всё это бессмысленно без желания поковырять и выжать максимум из конкретных приложений.

Добавлено спустя 12 минут 33 секунды:
Ну и схема питания ОС тоже занимается манипуляцией потоками по "общему" алгоритму. Особенно если парковка включена. Там же не только настройки распределения на P или E ядра.
Настройки для HT\SMT в схеме появились только в совсем новых билдах, не помню точно каких. Но точно не раньше 22H2, возможно даже 23H2. С такой скоростью адаптации дожидаться вменяемых алгоритмов можно очень долго...

Речь шла об E-ядрах в играх. На гибриде выяснить чистую производительность Е-ядер отдельно в играх не выйдет.

Именно это я и писал:

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

А то, что ты видишь, это просто драйвер видеокарты скорее всего. Его клиент работает в отдельном процессе и вот уже он действительно может висеть где угодно, независимо от тестируемой программы. Если извратиться, то DWM и остальные приблуды можно перевесить на любое ядро, но это можно сделать только с правами пользователя SYSTEM. Обычные пользователи и админ этого не смогут.

Всё понимаю и знаю. Только часть библиотек не в пространстве пользователя висит, их просто пользователь дёргает через API.

Это может быть что угодно, но главное что оно выполняется на P-ядрах, а не на E-ядрах при тестах в играх. Ну и напомню.