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

[_MBK_]

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

физических ядер

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

 

[andrejK]

Чо докопался до человека, Мишаня?
У него в тыщу раз все быстрее стало работать.

 

[_MBK_]

Чо докопался до человека, Мишаня?

Зря я что ли сутки терпел?

 

[veretragna]

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

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

ваш нагугленный vbs код считает количество логических ядер

Неверно, мой процессор имеет поддержку Hyperthreading и 8 логических ядер. То, что нагугленный код показывает 4, значит, что он считает физические ядра.

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

 

[veretragna]

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

Скажете, что docs.microsoft.com обманывает, а вы владеете незыблемой истиной?

 

[_MBK_]

в собственных процессах, или в собственных потоках.

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

Четыре потока, требующие процессорного времени, автоматически распределяются по ядрам, что подтверждается данными, которые предоставляет виджет.

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

То, что нагугленный код показывает 4, значит, что он считает физические ядра.

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

 

[_MBK_]

Скажете, что docs.microsoft.com обманывает, а вы владеете незыблемой истиной?

Да хотя бы абзацем ниже гляньте

 

[George]

Допустим, это не ядра напрягаются, а мифический эфир на полях плоской Земли. И, таки шо? Главное, что ТС видит ускорение работы скрипта в три раза, не?

 

[veretragna]

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

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

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

Я четко понимаю, что требуется.
Таски асинхронного экспорта выполняются в отдельных потоках. Моя задача - ограничить количество тасков (и, соответственно, потоков), чтобы их количество не превышало количество физических ядер, которые одновременно могут с ними работать.
То, что потоки распределяются по ядрам равномерно и самостоятельно, факт, скриншоты есть выше в теме.
Вы не понимаете, почему я хочу работать с физическими ядрами, а не с логическими?
С физическими ядрами удобно работать - проц не перегревается, остается запас мощности для другого ПО, и не возникает затыков из-за того, что один FPU может обслуживать только одно логическое ядро.

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

Да какая разница, точен или не точен, если он делает запрос по правильному адресу и получает верные данные?
Мне нужно количество физических ядер, а не серийник.
Упростим задачу - без частностей, без многопроцессорных систем, и не колхоз на основе процессора AMD с выключенными в биосе ядрами.

Да хотя бы абзацем ниже гляньте

Я исхожу из предположения, что инструменты администрирования Windows предоставляют правильную информацию. Если SMBios предоставил винде такое количество ядер, то винда располагает только такой информацией, и это не повод подключать к скрипту InDesign CPU-Z.

 

[veretragna]

Допустим, это не ядра напрягаются, а мифический эфир на полях плоской Земли. И, таки шо? Главное, что ТС видит ускорение работы скрипта в три раза, не?

И это объективный результат.
24 секунды и 66 секунд - существенная разница во времени выполнения

 

[_MBK_]

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

У вас оптимизация весьма опосредованная - вы строите ее на целой пирамиде предположений: WMI честно скажет сколько физических ядер; виндовый низкоуровневый планировщик честно даст каждому потоку долбящему винт свое отдельное ядро (при этом в системе не будет никаких иных потоков тоже долбящих винт в другое место); и наконец, индийский интерпретатор запустит экспорт в отдельном системном потоке.
Ну например, вот вы говорите у вас четыре физических ядра - так? Попробуйте пять задач экспорта запустить - экспорт захлебнется?

 

[veretragna]

У вас оптимизация весьма опосредованная - вы строите ее на целой пирамиде предположений: WMI честно скажет сколько физических ядер; виндовый низкоуровневый планировщик честно даст каждому потоку долбящему винт свое отдельное ядро (при этом в системе не будет никаких иных потоков тоже долбящих винт в другое место); и наконец, индийский интерпретатор запустит экспорт в отдельном системном потоке.
Ну например, вот вы говорите у вас четыре физических ядра - так? Попробуйте пять задач экспорта запустить - экспорт захлебнется?

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

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

На 5 задачах экспорт не захлебывается, а на проекте из 3 файлов, каждый из которых нужно вывести в 4 форматах, захлебывается.

 

[_MBK_]

На 5 задачах экспорт не захлебывается,

Как это не захлебывается? По вашей логике, при любом количестве BackgroundTask>NumberOfCores экспорт должен захлебнуться ибо ядер каждому потоку не хватает. И где тогда ваше экспериментальное подтверждение?

 

[veretragna]

Как это не захлебывается? По вашей логике, при любом количестве BackgroundTask>NumberOfCores экспорт должен захлебнуться ибо ядер каждому потоку не хватает. И где тогда ваше экспериментальное подтверждение?

А кто сказал, что при любом количестве BackgroundTask>NumberOfCores экспорт должен захлебнуться?
Приведите сообщение, где я это утверждал.
Я работаю с большим количеством документов и ставлю такое ограничение, которое лично мне кажется правильным - из расчета не более 1 потока на 1 ядро.

 

[_MBK_]

Это ключевая фраза

которое лично мне кажется правильным

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

Но, повторяю, я ничего не имею против

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

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

 

[veretragna]

На практике мы видим что десятки тредов превосходно себя чувствуют на четырех ядрах

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

 

[veretragna]

Или, что еще хуже, начинают сыпать вот таким

 

[veretragna]

Странно, правда, почему именно по одному ядру на таск а не по два или полтора?

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

 

[_MBK_]

Это ваше предположение, но я рад, что у вас все хорошо.

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

 

[_MBK_]

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

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