Сейчас существуют CPU для которых не нужна настройка в Bios?

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

Реальная задача - это 100% нагрузка, кодирование видео там, компиляция в rpcs3. Стресс-тест - это нагрузка больше 100% за счёт арбузинга жрущих инструкций. У тебя что при 80С?

Я своему AMD Ryzen Threadripper 3960X 24-Core Processor только профиль вентилей настроил под себя и всё, никакие напряжения и частоты не трогал

Это просто плохой кулер. Норм кулер держит 280+ ватт

В ноуте AMD Ryzen 7 5800H with Radeon Graphics, ничего не настраивал

Есть, Xeon GOLD какой-нибудь. Берёшь серверную платформу, вставляешь 2 штуки по 32 ядра и 64 потока в каждом и работаешь.

Только кондиционер в серверной повесь.

Этим занимается фирмварь, а не ос. ОС тут - пятое колесо.

? Накалка же.

Ну да, конечно, планировщику потоков не нужно знать что происходит с ядром, на которое она кидает/не кидает задачу.

Ему об этом сообщат.

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

Логика планировщика «кину задачу на пустое ядро с максимальной частоной потому что там она выполнится быстрее» принципиально конфликтует с логикой биоса «вот это ядро пустое, значит ставим частоту на минимум»

чужую работу

Что за работа такая?

по идее сам должен говорить какую частот у выставить

4.2

Логика планировщика … принципиально конфликтует

Проблема твоего планировщика.

Что за работа такая?

Очевидно оптимальный разброс задач по ядрам. Вот есть пустое ядро. Надо не ждать пока оно каким то образом станет быстрым а сказать ему чтобы оно стало и кинуть на неё задачу. А то со всеми этими биг.ЛИТТЛ по 5 лет не могут отладить трешинг задач между ядрами и вообще отключение турбобуста в половине случаев улучшает работу - это факт.

4.2

404 головного мозга.

Он не мой, он у всех такой.

404 головного мозга.

Я не спрашивал что у тебя за диагноз, но ладно.

Он не мой, он у всех такой.

4.2

отключение турбобуста в половине случаев улучшает работу

4.2

Надо не ждать пока оно каким то образом станет быстрым

А никто и не ждёт. Но быстрым оно может не стать по комплексу причин.

cказать ему чтобы оно стало и кинуть на неё задачу

Это делается в виде хинта фирмвари, а она дальше сама разбирается что на самом деле делать.

4.2
4.2
Я не спрашивал что у тебя за диагноз, но ладно.

А это не у меня диагноз...

Но быстрым оно может не стать по комплексу причин.

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

Это делается в виде хинта фирмвари, а она дальше сама разбирается что на самом деле делать.

Это делается вышвыриванием «умного» кода и дёрганьем двух вызовов АПИ: «подними частоту ядра до Х» и «ОК/я не шмогла». Вся логика уже есть в говенорах линукса и опционально в cpufreqd, хотя засунуть в говеноры ещё и обработку обратной связи по температурам - ну прям нереально сложно же.

В виндах кстати всё то же самое, и даже интел пилит свой собственный cpufreqd, правда пока только под 14-е поколение.

не у меня диагноз…

Покажи справку.

в идеале

Так не бывает.

дёрганьем двух вызовов АПИ: «подними частоту ядра до Х» и «ОК/я не шмогла»

Примерно так оно и стало с переходом на фирмварь(amd-pstate/intel_pstate).

Это делается вышвыриванием «умного» кода

Вся логика уже есть в говенорах линукса и опционально в cpufreqd, хотя засунуть в говеноры ещё и обработку обратной связи по температурам

Поделил на ноль.

Так не бывает.

Бывает. Если отключить буст и запустить cpufreqd.

4.2 Так ты тупо отрезаешь например 30% производительности процессора.

Примерно так оно и стало с переходом на фирмварь(amd-pstate/intel_pstate).

Тогда эта тема не возникла бы. Ну и вообще интелу не потребовалось бы 2 подхода по пилению винды чтобы их цпу перестал творить фигню.

5-10%. И то, если производитель настолько тупой, что не догадается переназначить буст-частоты в стандартный рабочий диапазон. Хотя кажется на оверклокерских моделях это можно сделать и самостоятельно

если производитель настолько тупой, что не догадается переназначить буст-частоты

Ошибаешься, юзерспейсный говернор всё равно медленнее аппаратного.

Тогда эта тема не возникла бы.

Конечно возникла бы, маркетинг не дремлет.

мгновенный накал до 80+ предотвратить всё равно не может

А зачем предотвращать его?

Такие резкие перепады температуры - нездоровая херня.

Чем выше температура, тем внезапно больше напряжения требуется для работы на той же частоте. Чем выше напряжение, тем выше температура. Получается рекурсия, называется thermal runaway.

ибо трупобуст

Пытаюсь с ним бороца, но пока безуспешно.

Ошибаешься, юзерспейсный говернор всё равно медленнее аппаратного.

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

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

ядерный

+-Одна хрень.

И ему не надо быть мегабыстрым

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

достаточно не сильно грузить цпу

Аппаратный вообще не грузит.

Берешь, собираешь нормальный кастом луп в нормальном корпусе и не жужжишь.

Конечно надо,

Не надо. Даже современные ЦПУ не успеют перегреться за 0,02мс (дефолтная частота опроса говенором), да и потери производительности от такой задержки поднятия частоты будут неопределимы.

И вообще, механизмы cpufreq уже 20 лет великолепно работают в диапазоне от 0 до 80-90% производительности процессора, так почему бы не прекратить эти пляски с бубном и не отдать тому же механизму верхние 10-20%?

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

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

Вот как раз напряжением ОС управлять не нужно. Биос вполне сам в состоянии настроить, запомнить и отработать кривую частота/напряжение. К тому же у нас есть не только вызов «выстави частоту Х на ядро N», но и ответ «я не шмогла, горячо/напряжение низкое/питания не хватает».

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

Это типа «а давайте будем работать в пределах 1 градуса от аварийного отключения»? Не, я понимаю что у интела не так уж много способов конкурировать в бенчмарках, но меру маразма тоже надо знать.

Аппаратный вообще не грузит.

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

Не надо

4.2

не успеют перегреться

Успевают, но программные средства эти пики температуры зарегистрировать не успевают, но они отражаются в виде требования повышенного напряжения.

cpufreq уже 20 лет великолепно работают

4.2 На феноме была измеримая просадка от ondemand относительно performance.

Ну не бывает так, чтобы 2 регулятора

Это ты сам себе придумал чучело и его пугаешься. Что на самом деле происходит это отсос программного говернора на roundtrip, заниженных частотах и завышенном напряжении.

Вот как раз напряжением ОС управлять не нужно

Почему только? Это всё работает только в комплексе и взаимосвязано.

Это типа «а давайте будем работать в пределах 1 градуса от аварийного отключения

И к чему это ты? Аварийное отключение происходит на выставленной от балды производителем температуре, если он сейчас на твоём процессоре её изменит то что случится, cpufreq станет говном внезапно?

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

Говно твой говернор тогда, я же говорю. Нормальный бы отсеивал высокочастотный шум.

тротлинг, и вот тут то и начинается веселье

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

но они отражаются в виде требования повышенного напряжения.

А что по твоему заставляет цпу вылетать в неэффективный режим тепловыделения, если не работа в аварийном режиме, в котором (по твоим же уверениям) для него 0,02мс слишком долго? Может нехрен вообще выходить на эту частоту, если не то что юзер, не каждый бенчмарк увидит этот буст (а некоторые так вообще увидят просадку)?

Кстати, напомню что этот великолепный турбобуст никак не повышает частоту оперативки и системной шины, так что КПД данного процесса ещё ниже ожидаемого падения.

4.2 На феноме была измеримая просадка от ondemand относительно performance

Ну а на RPi4 есть огромная просадка по тротлингу, на современных цпу есть очень измеримое снижение разницы между средним и 5% самых меделнных кадров при отключении буста, а на АМД А есть снижение на 2 ступени вентилятора в простейших задачах при отключении буста при незаметной потере отзывчивости.

Что на самом деле происходит это отсос программного говернора на roundtrip, заниженных частотах и завышенном напряжении.

О да, я вижу этот отсос!

На феноме была измеримая просадка от ondemand относительно performance.

Ты его ещё с powersave сравни. Совершенно внезапно режим под названием «performance» даёт большую производительность чем тот, который не называется «performance». Вот это поворот! И для этого потребовалось провести тестовые замеры потому что невооружённым взглядом никто бы и не догадался.

Это всё работает только в комплексе и взаимосвязано.

Примерно по той же причине, по которой ОС не нужно управлять напряжением на 12В шине питания. Простейший интегрированный модуль в схеме питания справляется лучше даже если он не программируемый. А уж если там можно 2-3 коэфицена задать, так и вообще ОС там делать нечего.

Аварийное отключение происходит на выставленной от балды производителем температуре

4.2 Ни один идиот не будет выставляь её от балды и тем более занижать ниже требований задачи.

если он сейчас на твоём процессоре её изменит то что случится, cpufreq станет говном внезапно?

Ну, видимо ты совсем НХНП.

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

А ещё кто то тут втирал про связь напряжения и температуры, а рост напряжения на чипе это внезапно ещё больше тепла и ещё больший рост температуры. Ну так давайте максимально задерём температуру, прям под самое горлышко от лимита, чтобы перегрев мог наступить быстрее чем за 0,1мс и будем героически решать ещё и эту проблему!

Говно твой говернор тогда, я же говорю

Только вот не говенор отвечает за разброс процессов.

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

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

А ведь можно было бы заранее охлаждать ядра чтобы заранее перенести на них задачу и одновременно заранее включить там буст чтобы затем заранее, за 0,02мс до перегрева начать её перенос на другое, оствышее ядро. И работало бы это не как 3,5Ггц +5% буста, а как честный 5Ггц. Ну, по крайней мере в малопоточной нагрузке и всяких бенчах.

Современные чипы в «троттлинге» внезапно работают быстрее чем без него

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

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

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

в аварийном режиме

4.2 При аварии оно отключалось бы.

неэффективный режим тепловыделения

Что за режим такой? Нету такого режима, там непрерывная кривая, и рабочая точка на ней выбирается человеком.

Может нехрен вообще выходить на эту частоту

Чтобы замедлить процессор? Ну так это вред.

не повышает частоту оперативки

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

системной шины

4.2 Частота uncore управляется бустом.

Ну а на RPi4 есть огромная просадка по тротлингу

Земля пухом инвалидам.

снижение разницы между средним и 5% самых меделнных кадров при отключении буста

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

снижение на 2 ступени вентилятора

Общие принципы не меняются от конкретной температуры, оно всё одинаково один хрен работает и на 40 градусах.

О да, я вижу этот отсос!

Цифры не врут, «нинужна» - не аргумент.

Совершенно внезапно режим под названием «performance

Не тупи. Performance там это просто фиксированная частота, т.е. отсутвие управления частотой вообще. А вот на новом проце я не намерял разницы между performance и balanced.

А уж если там можно 2-3 коэфицена задать, так и вообще ОС там делать нечего

Вот, казалось ты был так близок к пониманию…

Ни один идиот не будет

Ну это явное 4.2

аварийному лимиту

Это штатный режим.

энергитически и вычислительно менее эффективный

4.2 Более эффективный, потому как работает быстрее, с градацией чуть ли не в считанные инструкции.

рваная скорость рабты потока приводит

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

необходимости говенора чаще перераспределять

Нету такой необходимости.

героически решать ещё и эту проблему!

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

выкинуть с него высокоприоритетную задачу (потратив на её перенос немного времени разумеется, но это же ведь окупится. Возможно) на более быстрое

Это сброс кэша, так что на более медленное.

абсолютно предсказумым если хоть немного подумать и ввести пару коэфицентов

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

А ведь можно было бы заранее

Я так понимаю ты намекаешь на аппаратный шедулер процессов…

Ты однозначно первый в этой вселенной утверждаешь

Неа, это просто ты традиционно не в курсе того что берёшься обсуждать. Это общеизвестно оверклокерам для nvidia начиная с kepler, amd zen1 и свежих интелов.

Они могли бы исключить пропуск тактов

Только замедлив процессор, что вред.

А вот в профессиональных решениях (хай-энд, энтерпрайз, продакшен) почему то буст не популярен

4.2 Xeon все с бустом как он только появился.

частоты занижают от максимальных

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