[ID CC-CC2022] Определение количества ядер CPU

[veretragna]

Ну вы ж сами только что выложили скрин с кучей активных threadов помимо вашего экспорта?

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

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

А почему нет? Процессорного времени точно хватит всем, если на из расчета на 8 ядер будет выполняться 8 потоков.
Если процессора хватает, но станет не хватать пропускной способности диска, можно раскошелиться на скоростное хранилище. Зависит от задачи и возможностей.

Ни вы ни я не знаем (и особо не интересно) как реализовано внутри BackgroundTask распределение времени.

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

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

То есть, вам не нравится, что я выбрал в качестве ограничителя количество процессорных ядер?
Ок, задайте ограничение 8, если вам так больше нравится.
На каком-то количестве тасков индизайн виснет намертво. На 4 тасках работает идеально, на 12 зависает.
Между 4 и 12 есть выбор вариаций комфорта. Можно оставить ограничение 4 и работать в индизайне так, что экспорт не чувствуется. Можно поставить 8 и наслаждаться периодическими лагами. Можно выставить 12 и ждать полчаса возле кипящего ноутбука.

 

[veretragna]

Ради справедливости отмечу, что ограничитель у индизайна все-таки есть - на 4-ядерном процессоре не может быть больше 4 одновременно выполняющихся тасков. Несколько версий назад (в пределах СС2018-2019) было не так - ограничителя не было, все таски выполнялись немедленно.
Но остальные таски даже в состоянии queued что-то делают - тянут данные и бешено жрут процессор, если их достаточно много.

 

[_MBK_]

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

Ну я уже объяснил почему. Дисковые процессы вообще чрезвычайно прожорливы. Если у вас в системе (не дай б-г) заведется какой нибудь Петя и потихоньку начнет шифровать винт, то его поток будет тоже весьма заметен (и отберет ядро у ваших тасков)

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

Это кстати весьма странно - почему система не оптимизирует работу, равномерно загружая все ядра?

То есть, вам не нравится, что я выбрал в качестве ограничителя количество процессорных ядер?
Ок, задайте ограничение 8, если вам так больше нравится.
На каком-то количестве тасков индизайн виснет намертво. на 4 тасках работает идеально, на 12 зависает.

Вообще говоря, научный подход предполагает следующее. У вас есть некая гипотеза - что максимальная производительность достигается при соотношении активных тасков и ядер 1:1
Для вас эта гипотеза не вызывает никакого сомнения и является аксиомой, Я показал вам, что на самом деле гипотеза весьма сомнительна, указав при этом ее уязвимые места. Пока что единственное рациональное звено - не надо нагружать сразу все кокосы на ишака, возить их надо по очереди. Однако, связь между количеством ядер и тасков весьма туманна. Надо ставить эксперименты - на разных компьютерах, разных процессорах и разных системах менять максимальное количество тасков и мерять производительность. Только набрав достаточно большую экспериментальную статистику можно будет о каком то подтверждении говорить. А так, результаты могут быть совсем парадоксальны - скажем, на 4 ядрах 5 тасков могут работать быстрее чем 4 и т д

 

[veretragna]

Ну я уже объяснил почему. Дисковые процессы вообще чрезвычайно прожорливы. Если у вас в системе (не дай б-г) заведется какой нибудь Петя и потихоньку начнет шифровать винт, то его поток будет тоже весьма заметен (и отберет ядро у ваших тасков)

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

то кстати весьма странно - почему система не оптимизирует работу, равномерно загружая все ядра?

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

Вообще говоря, научный подход предполагает следующее

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

 

[_MBK_]

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

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

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

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

 

[veretragna]

Посмотрите, в каких сущностях выполняется код, обработанный OpenMP. Уж не в тредах ли? Или в файберах?

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

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

 

[_MBK_]

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

Разумный выбор - ограничить количество тредов тем количеством, которое импирически работает оптимально. Все остальные принципы будут работать непредсказуемо, в зависимости от версии системы. Ибо хвост у слабосильного ишака может быть весьма длинным.

 

[veretragna]

Вот эмпирически на 4-ядерном проце (моем) оптимально работают 4 потока.
Еще вопросы?

 

[_MBK_]

Я за вас рад. Вот и ставьте 4 константой, как вам тут уже неоднократно умные люди советовали, зачем макаронного монстра изобретать? Ладно, попробую еще до вашего здравого смысла достучаться. Допустим, ни я ни вы принцип действия ишака не понимаем, более того, даже понять, насколько ишак здоровый, насколько хорошие, годные у него сердце, легкие и т д, без посмертного вскрытия мы не можем. Разница между мной и вами в том, что я предлагаю ограничиваться средним значением кокосов, которое один ишак гарантированно возит, а вы начинаете строить теории связи грузоподьемности ишака с длиной выступающих частей тела, которую можно измерить линейкой. Связь, бесспорно, имеется, однако так ли очевидна она, что на нее можно полагаться? Давайте рассудим здраво - количество активных тредов в системе может быть каким угодно, в том числе - примерно одинаково сильно нагруженных, главное, чтобы полностью систему не нагрузили - так? Но ведь у вас и чересчур большое количество тасков не систему перегружает, а индизайн - не так ли? Ошибки, которые вы скриншотили тоже явно индизайновские а не о исчерпании системных ресурсов. Так откуда уверенность что ишаку именно длинны хвоста недостает? Логичнее предположить, что индизайну банально не хватает каких то внутренних обьектных буферов, необходимых для одновременного экспорта, на это, кстати, косвенно какбэ намекает проблема, изложенная вами в соседнем топике - непонятное ограничение на одновременное использование копий профилей. Им что тоже ядер не хватает или как?

 

[Skvoznyak]

indesign server по уму надо ставить, если такие серьезные объемы, что 40 секунд имеют значение.
сколько помню - вечно с этим фоновым экспортом проблемы. прервется например где-то посередине, и даже номер страницы, где произошла ошибка не понять.

 

[veretragna]

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

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

я предлагаю ограничиваться средним значением кокосов

Вы предлагаете захардкодить в скрипте значение 4. Это среднее значение для 4-ядерного проца, но не для 2-ядерного или 6-ядерного. Вариант с количеством ядер гибче.

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

Так, похоже, возникло недопонимание.

С самого начала:
Первое.
Если количество тасков равно количеству ядер проца, они собирают данные и стартуют почти одновременно без малейших неудобств, при этом производительность такого процесса если не максимальна, то приближена к максимальной. Я не вижу смысла задействовать еще и логические ядра в этом деле, поскольку FPU всего один на физическое ядро, скорость обработки графики будет ограничена производительностью FPU для этого таска. Да и встроенный ограничитель индизайна не даст запустить больше тасков, чем в системе есть ядер.

Второе.
Чем больше queued тасков стоит в очереди за выполняющимися, тем больше и больше ресурсов queued таски жрут на какие-то свои внутренние процедуры, отнимая время у тех тасков, которые должны выполняться, что в конечном итоге приводит к зависанию индизайна. В момент, когда индизайн зависает с кучей тасков, процессор обычно кипит, загрузка всех логических ядер 100% под гипертредингом, а диспетчер задач запускается с трудом. Речь идет об исчерпании ресурсов системы. Никогда не было такого, чтобы индизайн крутился на 2 ядрах из 4 и зависал.
Этой проблемы можно избежать, не допуская в очередь лишние таски раньше времени.

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

indesign server по уму надо ставить, если такие серьезные объемы, что 40 секунд имеют значение.
сколько помню - вечно с этим фоновым экспортом проблемы. прервется например где-то посередине, и даже номер страницы, где произошла ошибка не понять.

Server нужно еще купить.
Не сказать, что объемы серьезные, но вот приходит мне пакет - два каталога и три брошюры, я с ними поработал и хочу правильно сохранить творение рук своих. Заказчик хочет PDF в высоком качестве, низком качестве, развороты и idml.
Казалось бы - простая задача, но 2 каталога и 3 брошюры в 4 форматах - это 20 тасков.

 

[~RA~]

Я не вижу смысла задействовать еще и логические ядра

А вы и этим управляете?
@_MBK_, наши с тобой аллегории не прошли даром, тс перестал называть таски тредами!

 

[_MBK_]

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

Вы предлагаете захардкодить в скрипте значение 4. Это среднее значение для 4-ядерного проца, но не для 2-ядерного или 6-ядерного. Вариант с количеством ядер гибче.

Так, похоже, возникло недопонимание.

С самого начала:
Первое.
Если количество тасков равно количеству ядер проца, они собирают данные и стартуют почти одновременно без малейших неудобств, при этом производительность такого процесса если не максимальна, то приближена к максимальной. Я не вижу смысла задействовать еще и логические ядра в этом деле, поскольку FPU всего один на физическое ядро, скорость обработки графики будет ограничена производительностью FPU для этого таска. Да и встроенный ограничитель индизайна не даст запустить больше тасков, чем в системе есть ядер.

Второе.
Чем больше queued тасков стоит в очереди за выполняющимися, тем больше и больше ресурсов queued таски жрут на какие-то свои внутренние процедуры, отнимая время у тех тасков, которые должны выполняться, что в конечном итоге приводит к зависанию индизайна. В момент, когда индизайн зависает с кучей тасков, процессор обычно кипит, загрузка всех логических ядер 100% под гипертредингом, а диспетчер задач запускается с трудом. Речь идет об исчерпании ресурсов системы. Никогда не было такого, чтобы индизайн крутился на 2 ядрах из 4 и зависал.
Этой проблемы можно избежать, не допуская в очередь лишние таски раньше времени.

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


Server нужно еще купить.
Не сказать, что объемы серьезные, но вот приходит мне пакет - два каталога и три брошюры, я с ними поработал и хочу правильно сохранить творение рук своих. Заказчик хочет PDF в высоком качестве, низком качестве, развороты и idml.
Казалось бы - простая задача, но 2 каталога и 3 брошюры в 4 форматах - это 20 тасков.

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

 

[veretragna]

А вы и этим управляете?

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

В момент, когда индизайн зависает с кучей тасков, процессор обычно кипит, загрузка всех логических ядер 100% под гипертредингом, а диспетчер задач запускается с трудом

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

@_MBK_, наши с тобой аллегории не прошли даром, тс перестал называть таски тредами!

"Экспорт в 4 потока", я так понимаю. Вам не нравится, что я сначала использовал слово "потоки"? Те самые потоки, которые наблюдал в нагрузке процессора, а потом обнаружил в списке потоков процесса?
И по поводу которых привел доказательства, что каждый backgroundTask выполняется в своем thread без жестко заданной affinity? Бросьте, это приемлемое упрощение, учитывая, что все таски выполняются в своих тредах.
В дальнейшем речь пошла конкретно о тасках индизайна, поэтому для этого обсуждения использовался термин "таски".

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

Я выдвинул теорию, и я первым ее опровергну, если окажусь неправ.
Если будет затык на слабых процах, можно предпринять ряд мер.
Если будет зависать при ограничении 8 тасков из расчета на 8 ядер, можно предпринять ряд мер.
Но вы не аргументируете, почему должен быть затык на слабых процах и почему индизайн должен зависать на 8 тасках, ссылаясь на свои умозрительно нарисованные объектные буферы, не подтверждая фактами ничего из заявленного.
У вас не получается аргументировать правильность своих утверждений.

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

 

[_MBK_]

У вас не получается аргументировать правильность своих утверждений.

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

 

[veretragna]

Если бы 5 потоков хрома кушали так много процессорного времени, как активные таски индизайна, система была бы в ступоре.

 

[_MBK_]

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

 

[veretragna]

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

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

Еще раз повторяю - при чем тут системный планировщик и ядерность процессора?

В индизайне одновременно активны 4 таска, они выполняются в отдельных потоках. Каждый такой поток потребляет много процессорного времени, поэтому системный планировщик потоков распределяет их так, чтобы они равномерно распределились по свободным ядрам. У меня дежавю, это я уже объяснял на пальцах и привел скриншоты с доказательствами, вы невнимательны.

Соседний топик - тема отдельного разговора.

 

[_MBK_]

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

Проблема из разряда - "я возьму несколько зонтиков по числу облаков на небе"

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

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

 

[veretragna]

На двухядерном проце эта логика ломается

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

Мы с вами обсуждаем сферического коня в вакууме.

Прямо в точку.

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