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

  • Автор темы Автор темы veretragna
  • Дата начала Дата начала
На крайний случай сгодится, но хочется сделать красиво и автоматически
 
Ну задайте жёстко 8 например. Вряд ли ваше творение будет запускаться на процессорах с бо́льшим количеством ядер.
 
Поздно, я все-таки расколол этот орешек.

2019-09-05_142112.png

JavaScript: 
var vbscript = 'Set objWMIService = GetObject("winmgmts:\\\\" & "." & "\\root\\CIMV2")\r' +
'Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Processor", "WQL", &h30)\r' +
'For Each objItem In colItems\r' +
'returnValue = objItem.NumberOfCores\r' +
'Next';

var cpuCores = app.doScript(vbscript,ScriptLanguage.VISUAL_BASIC); 

alert(cpuCores);
 
  • Спасибо
Реакции: dev9togo
на маке как работать будет?
 
Это прямое обращение к объекту COM винды, на маке придется выкручиваться иначе, если это вообще возможно. К сожалению, с маком никогда не работал, скрипты под мак тем более не писал.

В любом случае в качестве дефолтной опции буду ставить 4, если по какой-то причине в этой части кода не будет произведено обращение. 2-ядерные процы не должны захлебнуться, а 4-ядерные будут работать в штатном режиме
 
Мне пришла мысль на каждый созданный backgroundTask вешать свой eventListener, который при возникновении события будет закрывать документ. Помозгую над этим, когда возникнет необходимость
 
Оказывается, профили PDF в InDesign работают эксклюзивно.
Если у меня уже происходит asynchronousExportFile() с заданным профилем [High Quality Print], то этот профиль становится недоступным для следующего asynchronousExportFile() - все дальнейшие таски с этим профилем становятся queued и далее выполняются по одному.
Независимо от того, один это документ или разные документы, профиль блокируется, пока не завершится предыдущий таск.
Вот это чудеса в решете!
Убил бы нафиг.
 
ну это мелочи, можно установки из профиля взять одной строчкой и с ними экспортировать. а что, дофига времени реально экономится?
 
В том скрипте, на котором я тестировал, экономится уйма времени.
Он сделан, чтобы из одного документа InDesign делать PDF низкого качества, PDF высокого качества, PDF в виде разворотов и idml. Т.к. все таски идут в собственных потоках, навскидку получается вчетверо быстрее, чем по очереди, если не упрется в жесткий диск.
Все профили разные, поэтому они никогда не выпадают в queued.
Точно смогу сказать чуть позже, не за рабочим пк сейчас
 
Проверил.
Средненький такой документ на 18 страниц, текст, чуть картинок.

Экспортировал, как и говорил, PDF низкого качества, PDF высокого качества, PDF в виде разворотов и idml.

Многопоточный экспорт с asynchronousExportFile(): 24 секунды
Однопоточный экспорт по очереди с exportFile(): 1 минута 6 секунд

Тут еще и мой проц сыграл - при одном активном ядре у него Turboboost 3.6 ГГц, при всех активных 3.1 ГГц, но тем не менее.
 
Skvoznyak сказал(а):
ну это мелочи, можно установки из профиля взять одной строчкой и с ними экспортировать
Нажмите, чтобы раскрыть...
Есть пример? Если asynchronousExportFile() принимает в качестве профиля строку, полученную из PDFExportPreset.toSource(), было бы просто отлично, но пока не вижу в документации такого
 
сходу не напишу код, но смысл такой - делаете новый пресет в скрипте, и присваиваете ему .properties = PDFExportPreset.properties
 
Вот так не работает - ругается на пустой профиль.
JavaScript: 
var tps = new PDFExportPreset;
tps.properties = mainPDFExportPreset.properties;
Смотрю через браузер данных ESTK - в tps объявлено только свойство properties и какой-то метод, и все - больше ничего в объекте нет.
Думаю, может, создание профиля нужно выполнить как-то иначе, наверняка пропущен какой-то этап инициализации.
Продолжу утром - спать охота
 
Да уж, башка ночью совсем не варит. Через app.pdfExportPresets.add() профиль нормально создается
 
Для интересующихся - посмотрел немножко на картину внутри процесса.
Так и есть - для 4 асинхронных экспортов имеется 4 отдельных потока

threads.png
 
veretragna сказал(а):
Так и есть - для 4 асинхронных экспортов имеется 4 отдельных потока
Нажмите, чтобы раскрыть...
И что это доказывает? Там этих потоков как у дурака махорки, с чего вы взяли что каждый индизайновский объект BackgroundTask на низком уровне натягивается на отдельно взятое физическое ядро?
 
Это регулируется не индизайном, а системой.
Балансировщик потоков системы сам распределяет потоки по ядрам, и если в системе 4 ядра, каждый поток выполняется на своем ядре. Мой виджет показывает, что потоки автоматически перебрасываются между ядрами, если тасков меньше 4 - в одну секунду могут быть загружены ядра 1,2,4, в другую 1,3,4 (для примера).
Из этого я делаю вывод, что индизайн не вмешивается в обработку потоков и не задает им affinity.

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

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

Если удается соблюсти ограничение, балансировщик потоков системы сам разбросает их по ядрам, я и не собирался вмешиваться в механизм распределения.
 
  • Спасибо
Реакции: dev9togo
veretragna сказал(а):
Балансировщик потоков системы сам распределяет потоки по ядрам, и если в системе 4 ядра, каждый поток выполняется на своем ядре.
Нажмите, чтобы раскрыть...
Давайте все таки не путать мухи с котлетами. Откуда балансировщик системы знает про то, что в индизайновской объектной модели есть такой класс "BackgrounТask"? Смею предположить, что когда индусы явамашину лепили они ни про какой системный балансировщик потоков и не думали вообще. Разница между физическими ядрами и вашим высокоуровневым "планировщиком", как образно заметил Рома - примерно как между колокольней и небесной канцелярией.
Что касается количества нагруженных потоков - Кэп вам авторитетно заявляет, что наиболее грузит проц поток, непрерывно долбящий винт. А ядра тут причем и их количество?
 
Ему не обязательно знать про сущности в модели InDesign.
Главное, в каком виде InDesign подает поток на выполнение.

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

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

Я опять вынужден повторяться. Количество ядер при том, что нужно было задать ограничение, чтобы количество одновременно подающихся тасков не превышало количество физических ядер. Если количество тасков превышает количество ядер, индизайн зависает намертво.
Если потоков 4 и ядер 4, потоки разбрасываются по ядрам и все красиво работает.
Моя задача - обеспечить ограничение, чтобы планировщик тасков индизайна не захлебнулся.
 
Последнее редактирование:
Для ответа нужно войти/зарегистрироваться
Верх Низ