Pull to refresh

Comments 66

3.8Ггц это медленное, 4.0 это быстрое. Разница в 200Мгц или посчитаете в процентах, сколько это?
Сова и глобус.

Конкретные цифры лишь для примера. Речь о самом факте - разная скорость ядер внутри одного процессора, о чем ОС не в курсе.

200 мало, ладно. А 4x3800 против 4x4000 уже более существенно. У другого процессора может быть другая разница, вы бы обозначили сразу порог когда начинает иметь значение. Вам может и 1.3 Ггц (5.2-3.9) у i9-12900k разница - не важна. Но не надо говорить за всех. Кому и 100 МГц будет иметь значение, для них и статья.

По простому все что меньше 10% это погрешность. И не стоит на нее обращать внимания.

Это частный пример. Наверняка у более многоядерных процессоров разброс частот по-более 10%

Посещала мысль поменять процессор на E5-2696v4, у которого якобы максимум 3.7, а база лишь 2.2 - вот тут наверняка гораздо заметней было бы.

Было бы больше пользы, если б в комментариях просто делились статистикой частот по ядрам на других процессорах. Какая к примеру all core turbo у E5-2696v4 ? Информации ноль.

На самом деле на boost частотах все ядра сразу работать не могут. Обычно может только одно одновременно. И толку? В типичной серверной нагрузке это никак не поможет.

Измерения ради измерений получаются.

Вы тоже не читая, сразу комментировать?

Могут! У E5-1650v4 к примеру 3.6 якобы базовая, 3.8 boost (относительно базовой же) когда все ядра одновременно загружены и до 4.0 могут лишь 4 вполне конкретных ядра, даже одновременно. Но если подключится еще и 5е ядро, то выше 3.8 уже не будет ни на каком.

А типичная серверная нагрузка - нет такого. Все очень индивидуально. Где постоянно высокое LA - можно не заморачиваться действительно, выше all core turbo не будет почти никогда. А если нагрузка средняя или низкая, то есть смысл заморочиться. Но зависит конечно от пофигизма владельца.

И главный вопрос - где взять информацию по all core turbo частотам разных cpu? Я не нашел нигде. Только по прошедшим через меня процессорам имею записи.

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

Вы тоже не читая, сразу комментировать?

Да, не обратил внимания что вы про такое старье пишите. Этому процу уже на пенсию пора. Он по производительности на ватт только ест лишние деньги.

И главный вопрос - где взять информацию по all core turbo частотам разных cpu?

Нигде. Это теперь особенности реализации.

https://www.techpowerup.com/237740/on-intels-decision-to-no-longer-disclose-all-core-turbo

Спасибо, оч познавательно.

Как раз темой cpu governer занялся, чтобы cpu не жрал в простое на proxmox ve.

Накопал такое:

CPUFreq Governors https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
intel_pstate CPU Performance Scaling Driver https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html
amd-pstate CPU Performance Scaling Driver https://docs.kernel.org/admin-guide/pm/amd-pstate.html

> Какая к примеру all core turbo у E5-2696v4 ? Информации ноль.

https://xeon-e5450.ru/socket-2011-3/e5-2600-v4/xeon-e5-2696-v4/

и там же:

https://xeon-e5450.ru/socket-2011-3/e5-2600-v3/

https://xeon-e5450.ru/socket-2011-3/e5-1600-v4/

https://xeon-e5450.ru/socket-2011-3/e5-2600-v4/

Хороший ресурс, рекомендую.

P.s. Proxmox, ceph, zfs, pfsense и все-все-все https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/

Отлично. Т.е. у E5-2696v4 разброс от 3.7 до 2.8 - 900 МГц... тут выше носом вертели мол 200 МГц ни о чем.

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

Вообще существует теорема Неймана:одно ядро, один процессор, одна шина. Вот и страдаем мы ,что нет нормализации и фирма IBM отказывается от выпуска персоналок, а вообще фреймов. Не может обеспечить гарантийное сопровождение продукции. Вообще производство многослойных структур я предлагал еще в 1983году будучи студентом4 курса мрти. Правда первая цель была производство гетероструктур. А охлаждение структур это просто лекционный материал. Например элементы Пельтье. А вообще знаю парня из хорошей научной семьи, которого перевели к нам чертить за замечание на оперативке, что именно то что выкидывают из схемы ради экономии для термостабилизации. Вот и слушай после этого Чехов:"стоит обнаружить плату-и можно с нее просто выкусить штук 5 советских микросхем".

4 тысячи рублей стоит 12 ядерный 24 поточный 2678v3. И пусть задачи хоть обожрутся ядрами.

Кстати, оборотная сторона медали повышенной частоты - энергопотребление. Может лучше пусть ядра работают на 80% частоты, но жрут при этом (условно) вдвое меньше ?

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

Да нет, энергию как раз существенно можно сэкономить. Как раз из-за того, что частота (и как следствие производительность) нелинейно растет от энергопотребления. Это очень наглядно видно по eco mode у Zen 4 процессоров.

Из физики процесса - энергопотребление (и тепловыделение тоже) пропорционально квадрату частоты.
У вас есть основания считать, что для турбо-частот это не так (и если не так, то в какую сторону и почему)?

То есть фактически энергии вы экономите обратно пропорционально частоте.

Разумеется если речь идёт о хорошо параллелящемся процессе. Если вам нужно выжать максимум из 1 потока - добро пожаловать в турбо-буст.

Из физики процесса — энергопотребление (и тепловыделение тоже) пропорционально квадрату частоты.

интересно обоснование

А в чем вас фундаментальная сложность с физикой процесса в данном случае?

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


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

Ну, как не сожрет… 5950HX бустится до 4.8, температура подскакивает в один поток до 80°C со со спокойных 50–55.
В полной загрузке разогревается до 90, но с частотами ниже 4 по всем ядрам.
Крутилятор выходит на полные обороты уже с 75.
То есть, одно ядро кочегарит почти как ~6/12.

я не знаю как на 5950HX, но ryzen 5 3600 при 3 поточной нагрузке показывает температуры заметно выше, чем при 12 поточной. потому, что нагрев идёт точечный.
исходя из того что в однопотоке температура такая-же как и в многопотоке нельзя делать вывод о том, что энергопотребление одинаковое.

Пардон, 5900HX. Но разница не определяющая, конечно.
Это проц бучный, на испарительной камере, отъем тепла прямо с кристалла по всей поверхности, поэтому разница между точечным нагревом и распределенным — не слишком велика.
powertop отображает какую-то фигню, поэтому снять реальное потребление пока не представаляется возможным. Но можно оценить верхнюю границу: на мемтесте или в прошивке нагрузка однопоточная, и 90Вт·ч батарея высасывается за час с небольшим.
Согласно статье процессор может выкушивать до 90Вт без GPU… Что позволяет оценить потребление в одну нитку около 75Вт.

Да что ж никто не вникает в суть... Речь лишь про то, что не всягда все ядра одинаковы. И бывают ситуации, когда нужно получить максимум именно скорости. К примеру замер single-thread производительности в обычных условиях может пройти на турбо- и на не_турбо- ядрах с заметным отличием в результате. Или запускается что-то однопоточное очень очень долгое и вместо того чтоб довериться случаю, можно принудительно запустить это именно на чуть более быстром ядре. Либо наоборот, сделать чтоб гарантированно не влазили неважные процессы в быстрые ядра и чтоб с большей вероятностью что-то более важное выполнилось на них каплю быстрее.

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

Кому не интересно проходите мимо, никто не заставляет оставлять бессмысленный комментарий.

Недавно наткнулся на статью, где автор не только сталкивался с разной частотой ядер, но ещё и с тем, что у некоторых P ядер частота заметно колебалась, внося значительный шум (~25%) в результаты бенчмарков:

https://sillycross.github.io/2022/06/11/2022-06-11/

строить велосипеды ради 4%? увольте

А в чём тут велосипед? taskset же можно использовать не только ради распихивания по более крутым ядрам, но и более глобально — просто для управления Affinity.

потому что если нужно ручным управлением выжимать 4% и нет денег на железо, то это велосипед и колхоз

Ок. Допустим нужно получить максимальную однопоточную скорость. Но денег нет и покупается лишь i9-13900k (А были бы деньги, вот тогда бы ого-го какой более быстрый можно было взять конечно).

Запускаем и получаем нашу задачу, работающую на 4.3 ГГц вместо 5.8

Дальше что?

потому что если нужно ручным управлением выжимать 4%

Ну оно ручное, когда это 1 комп, и тот дома. А если таки серверов закупить хотя бы стойку, а руками-то надо 1 раз залезть, а потом на все серверы раскатать - получить 4% прироста на всю стойку это уже достаточно выгодно, когда серверы и так на последнем поколении процессоров и "просто апгрейдом" уже не решается.

только вот получившаяся конфигурация получается куда менее универсальной.
придёт всплеск запросов на mysql, например, а он ограничен всего несколькими ядрами, и мы уже получим кратную потерю производительности.

Дайте я угадаю. Вы веб программист?

кнут с его «преждевременная оптимизация — корень всех бед» тоже веб-программист?


для зануд: я знаю, что изначальное авторство фразы обсуждается, но в любом случае она будет постарше веб-программирования )

Судя по комментариям, статья принесла бы больше пользы, если бы в ней рассматривался реальный процессор с P и E ядрами, а не старый Xeon, где все ядра одинаковые. Там бы и разница была значительней, а также можно было посмотреть на работу Intel's Thread Director в Linux.

Службы - это частный случай опять же. Что-то же можно запустить просто так, не как службу.

В нашем случае E-ядра - зло(нам нужна одинаковая производительность всех ядер).

Поэтому в планах переход с Intel -> AMD

На ксеонах разве есть е ядра?

У тредрипперов АМД свои проблемы. Если пара потоков неудачно уедет на разные ядра то легко можно словить минус 30% производительности. Дебажить первый раз довольно тяжело. Расселить виртуалки правильно тоже бывает непросто.

У нас такая специфика, что мы используем процессоры для desktop.

Если конкретно, то мы поставляем аппаратно-программные комплексы. То есть ПО+железо.

Тогда в чем проблема? На десктопе всегда есть куча ерунды для е ядер. Мессенджер, музыка в фоне, текст кто-то печатает, что-то обновления проверить решило и все что угодно.

Посадить свою приложеньку на p ядра и не париться.

Вы какие-то не те цены смотрите. Они одинаково стоят. Плюс-минус в зависимости от поставщика и ситуации на рынке прямо сейчас.

https://www.dns-shop.ru/product/0a2114a7fcc9ed20/processor-intel-core-i5-12400f-oem/

https://www.dns-shop.ru/product/3239ebce09e93332/processor-amd-ryzen-5-5600x-oem/

https://nanoreview.net/en/cpu-compare/intel-core-i5-12400f-vs-amd-ryzen-5-5600x

Я говорил о полном комплекте для сборки ПК, а не только о процессоре.

Поставлять покупателю 2 современных ПК Intel VS 1 современный ПК AMD

ИМХО, мы выберем 2-й вариант, так как в этом случае себестоимость на полноценное ядро ниже.

Offtop: давайте закончим спор.

Да какой спор. Мне все еще интересно как вы умудряетесь собирать десктопы на АМД в два раза дешевле. При одинаковой стоимости процессоров и одинаковой стоимости всего остального.

Может я чего-то не знаю и переплачиваю в два раза? Покажите ссылочку на сборки в любом магазине.

> Если пара потоков неудачно уедет на разные ядра то легко можно словить минус 30% производительности.

Ну на [уже сколько лет] новых AMD просто двойная NUMA-архитектура (появился дополнительный слой объединения ядер).

То есть попросту если вы ловите какую-то проблему с memory affinity на Intel, то она будет (грубо по порядку величины) вдвое сильнее проявляться на AMD. С другой стороны если у вас типичная серверная нагрузка (обслуживаете, мелкие запросы, идеально на stateless серверах) - то у вас просто чуть не вдвое больше вычислительной мощности за те же деньги.

Ну на [уже сколько лет] новых AMD просто двойная NUMA-архитектура (появился дополнительный слой объединения ядер).

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


и да, у интела тоже может быть больше одной numa-ноды на сокет

Интересно, а вот в мобильных устройствах (в том числе и под Android, у которого родственное Linux ядро) не первый год уже используются процессоры с гетерогенной компоновкой big.LITTLE, где разница в частотах ещё более ощутимая, и там выбор ядер планировщиком явно не случаен. По идее, должны существовать какие-то готовые автоматизированные софтовые решения данного вопроса. Или они на «большой» Linux не портировались?

Energy Aware Scheduling вошло в мейнлайн еще где-то в районе 2015 года
и Capacity Aware Scheduling поддерживается тоже довольно долго.

Ну и у Интела конечно же NIH-синдром, так что будет еще Intel Thread Director в линуксе

и там выбор ядер планировщиком явно не случаен

Так под андроид свои планировщики и существуют с самого его начала. Во время повального увлечения перепрошивками народ даже сам планировщики писал.

Или они на «большой» Linux не портировались?

Всё так. Ну точнее, не портировались, потому что условный "большой линукс" никто не запускает на условном Qualcomm'овском проце, под который кто-то написал планировщик на андроид (до недавнего времени, да и даже сейчас ноутбуков на ARM, которые не Apple, практически нет на рынке).

Так себе решение. ОС сама должна знать о ядрах процессора всё. Бывают ядра настоящие, а бывают полученные через HyperThreading/SMT. Из той же серии "двухядерные" модули AMD у которых общий FPU. Есть ядра с разных процессоров, есть с разных кластеров (например, CCD/CCX у AMD) и гонять задачи желательно внутри одного кластера. Есть ядра разных архитектур (big.LITTLE в ARM, P/E ядра в 12-13 сериях Интел), есть отборные ядра у Интел, которые могут бустится до больших частот. CCD/CCX у AMD тоже разные, некоторые могут достигать больших частот. Во втором ThreadRipper часть ядер вообще могла не иметь прямой доступ к памяти.

Да и вообще современные процессоры бустятся по температуре/TDP и частота зависит от нагрузки на все ядра и от характера этой нагрузки.

Привязывать же потоки к конкретным ядрам зло. ОС сама должна знать все эти перечисленные особенности и распределять нагрузку максимально эффективно.

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

По правде особо не слежу, вроде в win11 что-то реализовано, но так понял слишком втупую - что на переднем плане, то на p ядрах, все что в фоне - на e ядрах. Свернул нужную задачу и она сильно замедлилась…

Знаете лучше решение, предлагайте.

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

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

И также должна иметь некий приоритет ядер, чтоб тяжелые задачи первыми использовали только p-ядра. Но если вдруг понадобится больше, могла также запускать и на e-, но только при полной занятости p-

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

Информацию о процессоре ОС может иметь как непосредственно в ядре, так и получать через драйвер.

У ОС есть статистика о поведении разных процессов, сами разработчики могут явно или неявно давать подсказки ОС. Для десктопных ОС опять же активный процесс/фоновый процесс, возможность задать приоритет в диспетчере задач/свойствах запускаемого модуля. Но лучше это делать как совет ОС, железке виднее как все нужно распределить.

И я не вижу ничего плохого в использовании P-ядер фоновыми процессами, если P-ядра свободны.

И также должна иметь некий приоритет ядер, чтоб тяжелые задачи первыми использовали только p-ядра. Но если вдруг понадобится больше, могла также запускать и на e-, но только при полной занятости p-

Это не так. Если задача нормально параллелится, то запуск одновременно на P и E ядрах даст больше производительности, чем только на P-ядрах, даже если во втором случае частота P ядер выше. Сейчас все упирается в TDP/температуру.

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

Потоки - это не ядра. Отключите hyper-threading на уровне BIOS и будет вам счастье. На высоко производительных задачах hyper-threading только мешает. На Вашем процессоре всего 4 ядра.

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

Есть E5-1630v4 и E5-1650v4 - у обоих только 2 ядра могут 4.0, остальные 3.8

Вот такой же 6-ядерный. Тоже лишь пара 0/6 и 5/11 могут до 4.0. У остальных 3.8 потолок.

У меня нет, но уверен, что у 8-ядерного E5-1680 v4 картина будет та же. Не знаю как у E5-26xx v4 дела обстоят.

Также есть из следующего поколения W-2125 - там все ядра одинаковы. У более старых E3-12xx v3 тоже одинаково было.

Где вы их достаете? Понятно, что v4 и ниже есть на али, а откуда W-2125?

Так говорите будто я вчера его купил. Они ведь в продаже давно и в магазинах США купить было не проблема... раньше.

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

Собственно мы имеем дело с сетью, которая требует синхронной или ассинхронной стабилизацией процесса вычислений. Еще лучше математическое разделение задач на подзадачи с прогнозированием необходимых мощностей для их совместного или раздельного решения. Т.. Е. Архитектура нейронной сети переключающейся в зависимости от прогноза необходимых вычислений.Естественно откинутые тупиковые решения выходят в резерв вычислительной мощностей и могут использоваться для оценки дальнейшего процесса вычислений

А вы проверяли как это будет работать в сочетании NUMA + "multiThreading" (а не MultiProcessing)?

А то вполне допускаю, что при cache-unfriendly доступе к памяти (разумеется надо тестить) второй вариант будет хуже, а именно его вы "заставляете" применить систему просто запрещая медленные ядра:
1. 4 быстрых ядра + 4 медленных ядра + "топологически родная память"
2. 4 быстрых ядра с родной памятью + 4 быстрых ядра с чужой памятью

Мне кажется, вы сделали неправильные выводы.
Возьмем ваш график от rrd, в нем видно, что красные ядра выше зеленых на них, НО, как несложно понять, это явно заметно только при полной загрузке процессора, нет на графике момента, когда зеленые были бы ниже, и вверх ушли бы красные(например на красное ядро ушла тяжелая однопоточная задача).
Я все к чему это говорю: вполне вероятно, что процессор не может задать максимальную частоту этим ядрам не потому, что они медленные с рождения, а потому, что у вас нагрузка процессора превышена по TDP, поэтому он замедляет эти ядра. Истина где-то в микрокоде. Это мое предположение того, что происходит у вас, у меня же есть процессоры 26xx v3 и v4, при этом v3 с модифицированным bios на матери и анлоком турбобуста на все ядра, и на предыдущем поколении я не могу подтвердить существование медленных ядер. Однако эффект снижения на 100-200мгц частоты я видел уже, это происходило при выполнении avx/avx2 инструкций на ядрах.

Я могу по отдельности нагрузить одно зеленое и одно красное. TDP не будет превышено, но зеленое выше 3.8 не будет.

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

Про avx известно. На моей домашней материнке в биос можно даже задать avx offset - на сколько ронять частоту. Но речь там опять же про все ядра, а не какие-то конкретно.

> Я могу по отдельности нагрузить одно зеленое и одно красное. TDP не будет превышено, но зеленое выше 3.8 не будет.
Вот именно этого статье и не хватало, при этом загружать надо без avx
То что турбобуст не на все ядра - это особенность моделей, в которые зашиты в микрокод режимы работы этого турбобуста.
Вот на таких ресурсах это все освещено https://xeon-e5450.ru/socket-2011-3/e5-1600-v3/e5-1650-v3/
Почему они так зашиты - это одному интелу известно, мб TDP, мб отбраковка ядер, на разных ревизиях тоже разная картина. Преодолеть зашитые режимы и разогнать ядра на процессоре тоже можно.

Sign up to leave a comment.

Articles