Чи є які-небудь системи побудови, які включають у графік відносний очікуваний час завдання?

Ось невелика ілюстрація мого питання:

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

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

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

На відміну від цього, якщо планувальник усвідомлює різницю між завданнями у часі, він може придумати такий значно коротший графік:

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

Мої запитання:

Чи є які-небудь системи побудови, які включають у графік відносний очікуваний час завдання?
Які академічні дослідження таких систем побудови?
Звідки ці системи побудови (якщо вони існують) беруть інформацію про час? Евристика, терміни, зібрані під час попередніх збірок?
Якщо таких систем побудови не існує, чому? Чи є гонча, яка зробила б їх менш вартими, ніж вони здаються на перший погляд?

scheduling research build-system

— sjakobi
джерело

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

— Док Браун

Я думаю, що це ґрунтується на неправильному припущенні, що "побудувати" завдання не паралельно.

— dagnelies

У більшості випадків побудова завдання дійсно є непаралельною, але так, наприклад, тести одиниць у багатопотокових програмах дійсно можуть бути паралельними. Насправді в проекті, де я працюю, ми завжди повинні викликати "make" з "-j1" для тестового прогону одиниці, тому що в іншому випадку багатоядерні тести, пов'язані з роботою, не вдається.

— juhist

@juhist Якщо вам цікаво перейти на більш виразну систему складання, у shake є концепція ресурсів, де ви можете, наприклад, визначити, скільки ядер CPU повинно бути зарезервовано для ваших тестових одиниць.

— sjakobi

Відповіді:

Командна система Visual Studio Microsoft (раніше TFS) враховує часи дії збірки та паралельні складання; він бере дані з попередньої історії збірки; і хоча я не вірю, що ти можеш отримати потрібну поведінку з коробки, ти, можливо, зможеш її налаштувати.

Приклад деяких спеціальних завдань для роботи над оптимізацією продуктивності

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

— Бруно Гвардія
джерело

Якщо я правильно розумію вашу відповідь та ваше посилання, повідомляються часи дій збірки (що є досить загальною ознакою), але не зрозуміло, чи можуть ці терміни використовуватись для вдосконалення графіка збирання. Схоже, це не відповідає моїм оригінальним питанням, тому я не присуджую нагороду за вашу відповідь.

— sjakobi

Без проблем, те, що ви, можливо, пропустили, це те, що ви можете налаштувати дії збирання та процес збирання за допомогою програмування. Вибірка мала звітність, але, як було зазначено, історія береться для автоматичних оптимізацій. Також зауважте, що ви можете налаштувати паралельні складання. Але тоді, щоб переконатися, що вони паралельні за вашим алгоритмом, можливо, вам доведеться налаштувати код. Деякі додаткові посилання: dotnetcurry.com/visualstudio/1177/…

— Бруно Гвардія

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

— Док Браун

Це ґрунтується на помилковому припущенні, що "побудувати" завдання не паралельно.

Багато компіляторів працюють багатопотоково, тому в одному завданні A використовуються всі процесори. Тому порядок не має значення. Для завдань, пов'язаних з введенням-виводу, особливо із залученням мереж, краще запустити їх все паралельно з самого початку: більшість часу буде витрачено на очікування відповіді.

Іншими словами, замовлення не має значення, оскільки окремі завдання, як правило, паралельні (наприклад, компіляція, наприклад)

Редагувати:

Власне, таке поняття "Завдання A на процесорі 1" теж є недоліком. Навіть для одиночних потокових завдань планування ОС процесів / потоків може переходити від CPU до CPU на кожному контекстному комутаторі. Я думаю, що більшість систем побудови просто виконуватимуть усі завдання паралельно і дозволять ОС робити планування. Більш тривалі завдання займатимуть більше часу, і це стосується цього.

Якщо припустити, що у вас є тривале завдання з однопотоковою передачею, яке не пов'язане введення-виведення , системі побудови було б простіше присвоїти йому пріоритет / важливість, а не намагатися затримати менші завдання, щоб зменшити контекстні комутатори з ОС.

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

— дагнелі
джерело

Паралелізм "всередині завдання" є цікавим аспектом і, безумовно, пропонує додатковий потенціал для оптимізації, але я не думаю, що припускати, що будь-яке завдання буде масштабуватися ефективно до довільної кількості процесорів, є кращим, ніж припускати, що кожне завдання повинно працювати на єдине ядро.

— sjakobi

@sjakobi: ну на практиці досить важливо, щоб компілятори були ефективними. Чи можете ви уявити, що довго чекаєте свого складання, оскільки використовується лише 1 з ваших 16 ядер? Це не виїзд. З усією теорією ви ніби не помічаєте реальність. Планування - дуже цікава та дуже змістовна тема. Це просто IMHO порівняно марно в контексті побудови систем. Знову ж таки, більшість компіляторів нині так чи інакше багатопоточні ... а якщо їх немає, то в цій системі швидше планування збірки слід докласти зусиль.

— dagnelies

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

— Базиль Старинкевич

@BasileStarynkevitch: ... справді. В основному всі здорові використовують, -j <nb-cores>але, на жаль, за замовчуванням все ще "1" ... Я все ще дивуюсь, що він ніколи не змінювався.

— dagnelies

@dagnelies: Існує величезна кількість Makefiles, які пропускають деякі критичні залежності і, отже, не працюють (або можуть не працювати) з -jN, де N> 1.

— juhist