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

Вот небольшая иллюстрация моего вопроса:

Предположим, что задание на сборку состоит из 4 независимых задач с именем AD. D занимает больше времени, чем AC в сумме.

Система сборки, которая не может включать относительное время выполнения задачи, может планировать задачи следующим образом:

---------------------------------------
CPU1: A  |    C   |
---------------------------------------
CPU2: B    | D                        |
---------------------------------------

Напротив, если планировщик знает о различиях времени задачи, он может придумать гораздо более короткий график:

---------------------------------------
CPU1: A  |  B    |   C   |
---------------------------------------
CPU2: D                        |
---------------------------------------

Мои вопросы:

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

scheduling research build-system sjakobi
источник

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

Док Браун

Я думаю, что это основано на неправильном предположении, что «построение» задачи не является параллельным.

В большинстве случаев построение задачи действительно не является параллельным, но да, например, модульные тесты в многопоточных приложениях действительно могут быть параллельными. На самом деле, в проекте, где я работаю, мы всегда должны вызывать «make» с «-j1» для запуска модульного теста, потому что в противном случае многоядерные тесты, связанные с производительностью, не пройдут.

юхист

@juhist Если вы заинтересованы в переходе на более выразительную систему сборки, у Shake есть концепция ресурсов, где вы можете, например, определить, сколько ядер ЦП следует зарезервировать для ваших модульных тестов.

Сякоби

Ответы:

Microsoft Visual Studio Team System (ранее TFS) учитывает время сборки и параллельные сборки; он берет данные из предыдущей истории сборки; и хотя я не верю, что вы можете получить желаемое поведение из коробки, вы можете настроить его.

Пример некоторых пользовательских задач для работы по оптимизации производительности

https://veegens.wordpress.com/2013/03/26/tfs-2010-build-performance-report/

Бруно Гардиа
источник

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

Сякоби

Нет проблем, что вы, возможно, упустили, это то, что вы можете настроить действия по сборке и процесс сборки с помощью программирования. Образец сообщал, но, как уже говорилось, история берется для автоматической оптимизации. Также обратите внимание, что вы можете настроить параллельные сборки. Но затем, чтобы убедиться, что они распараллелены в соответствии с вашим алгоритмом, вам может потребоваться выполнить настройку с помощью кода. Некоторые дополнительные ссылки: dotnetcurry.com/visualstudio/1177/…

Бруно Гуардиа

@BrunoGuardia: можете ли вы объяснить, где в этой статье по вашей ссылке упоминается опция настройки, которая может помочь использовать ожидаемое время выполнения действий при сборке?

Док Браун

Это основано на неправильном предположении, что «построение» задачи не является параллельным.

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

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

Редактировать:

На самом деле, эта концепция «Задача А на ЦП 1» тоже ошибочна. Даже для однопоточных задач ОС, планируя процессы / потоки, может перепрыгивать его с ЦП на ЦП при каждом переключении контекста. Я предполагаю, что большинство систем сборки будут просто выполнять все задачи параллельно и позволять ОС выполнять планирование. Более длинные задачи займут больше времени, и это все.

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

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

dagnelies
источник

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

Сякоби

@sjakobi: на практике очень важно, чтобы компиляторы были эффективными. Можете ли вы себе представить, что вы долго ждете компиляции, потому что используется только 1 из ваших 16 ядер? Это не пойдет. Со всей теорией вы, кажется, упускаете из виду реальность. Планирование - очень интересная и очень значимая тема. Это просто ИМХО относительно бесполезно в контексте систем сборки. Опять же, в настоящее время большинство компиляторов в любом случае являются многопоточными ... и, если это не так, следует скорее приложить усилия, а не планировать сборку.

dagnelies

Все компиляторы свободного программного обеспечения ( GCC & Clang ...) для C ++ или C, Fortran или Ada являются однопоточными. Система сборки ( make -j) может запускать несколько процессов компиляции параллельно.

Старынкевич

@BasileStarynkevitch: ... действительно. В основном, все вменяемые, -j <nb-cores>но, к сожалению, по умолчанию все равно «1» ... Я все еще удивлен, что это никогда не менялось.

dagnelies

@dagnelies: существует огромное количество файлов Makefile, которые пропускают некоторые критические зависимости и поэтому не работают (или могут не работать) с -jN, где N> 1.

югист