Esistono sistemi di build che incorporano i tempi relativi relativi alle attività previste nella pianificazione?

Ecco una piccola illustrazione della mia domanda:

Assumi un lavoro di compilazione che consiste in 4 attività indipendenti denominate AD. D impiega più tempo di AC in somma.

Un sistema di generazione che non è in grado di incorporare i relativi tempi delle attività potrebbe pianificare le attività in questo modo:

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

Al contrario, se lo scheduler è a conoscenza delle differenze temporali dell'attività, potrebbe venire con questa pianificazione molto più breve:

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

Le mie domande:

Esistono sistemi di build che incorporano i tempi relativi relativi alle attività previste nella pianificazione?
Quale ricerca accademica su sistemi di costruzione di questo tipo esiste?
Da dove prendono questi sistemi di compilazione (se esistono) le informazioni sul tempo? Euristica, tempistiche raccolte durante le build precedenti?
Se tali sistemi di build non esistono, perché? C'è un gotcha che li renderebbe meno meritevoli di quanto appaiano a prima vista?

scheduling research build-system

— sjakobi
fonte

La maggior parte delle domande per risorse o strumenti di terze parti viene chiusa rapidamente come "off-topic", ma immagino che questo potrebbe essere un caso limite che sembra adattarsi bene allo scopo di questo sito.

— Doc Brown,

Penso che questo si basi sul presupposto errato che "costruire" un'attività non sia parallela.

— Dagnelies

Nella maggior parte dei casi, la creazione di un'attività è effettivamente non parallela, ma sì, ad esempio i test unitari in applicazioni multi-thread possono essere effettivamente paralleli. In realtà, in un progetto in cui lavoro, dobbiamo sempre invocare "make" con "-j1" per l'esecuzione dell'unità di test, perché altrimenti i test di unità multicore relativi alle prestazioni falliscono.

— juhist,

@juhist Nel caso tu sia interessato a passare a un sistema di build più espressivo, shake ha un concetto di risorse in cui puoi ad esempio definire quanti core della CPU dovrebbero essere riservati per i tuoi test unitari.

— Sjakobi,

Risposte:

Microsoft Visual Studio Team System (precedentemente TFS) considera i tempi di azione della build e le build parallele; prende i dati dalla cronologia di build precedente; e anche se non credo che tu possa ottenere immediatamente il comportamento che desideri, potresti essere in grado di personalizzarlo.

Un esempio di alcune attività personalizzate per lavorare sull'ottimizzazione delle prestazioni

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

— Bruno Guardia
fonte

Se capisco correttamente la tua risposta e il tuo link, vengono riportati i tempi di azione della build (che è una caratteristica piuttosto comune) ma non è chiaro se o come questi tempi potrebbero essere usati per migliorare il programma di build. Questo non sembra rispondere alle mie domande originali, quindi non assegnerò la generosità alla tua risposta.

— Sjakobi,

Nessun problema, quello che potresti aver perso è che puoi personalizzare le azioni di compilazione e il processo di compilazione, attraverso la programmazione. Il campione riportava, ma come detto, la cronologia viene presa per le ottimizzazioni automatiche. Inoltre, tieni presente che puoi configurare build parallele. Ma poi per assicurarti che siano parallelizzati seguendo il tuo algoritmo, potresti dover personalizzare con il codice. Qualche riferimento aggiuntivo: dotnetcurry.com/visualstudio/1177/…

— Bruno Guardia,

@BrunoGuardia: puoi spiegare dove in quell'articolo del tuo link è menzionata un'opzione di personalizzazione che potrebbe aiutare a utilizzare i tempi previsti delle azioni di compilazione?

— Doc Brown

Ciò si basa sull'ipotesi errata che "costruire" un'attività non sia parallela.

Molti compilatori funzionano con più thread, quindi una singola attività A utilizzerà tutte le CPU. Pertanto, l'ordine non ha importanza. Per le attività associate agli I / O, in particolare per quanto riguarda il networking, è meglio avviarle tutte in parallelo fin dall'inizio: la maggior parte del tempo sarà spesa in attesa di una risposta.

In altre parole, l'ordinamento non ha importanza poiché le singole attività sono in genere parallelizzate (come la compilazione ad esempio)

Modificare:

In realtà, anche questa concezione di "Task A su CPU 1" è errata. Anche per attività a thread singolo, il sistema operativo che pianifica i processi / thread può passare da CPU a CPU su ogni interruttore di contesto. Immagino che la maggior parte dei sistemi di build eseguirà tutte le attività in parallelo e consentirà al sistema operativo di eseguire la pianificazione. Compiti più lunghi richiederanno più tempo e questo è tutto.

Supponendo di avere un'attività a thread singolo in esecuzione a lungo che non è associata a I / O , sarebbe molto più facile per il sistema di generazione assegnargli una priorità / importanza piuttosto che tentare di ritardare attività più piccole per ridurre i cambi di contesto dal sistema operativo.

Anche se hai compiti così strani , che è abbastanza raro nella pratica, e hai un sistema di compilazione di pianificazione elaborato che funziona su euristica basata su esecuzioni precedenti (l'unico modo per saperlo), i vantaggi che ne ottieni potrebbero essere piuttosto piccoli .. Tuttavia, ottieni un sacco di complessità aggiuntiva da mantenere.

— dagnelies
fonte

Il parallelismo "all'interno di un compito" è un aspetto interessante e offre sicuramente un ulteriore potenziale di ottimizzazione, ma non penso che supporre che un determinato compito si ridimensioni in modo efficiente a un numero arbitrario di CPU sia meglio di supporre che ogni compito debba essere eseguito su un singolo core.

— sjakobi,

@sjakobi: bene, in pratica è abbastanza importante che i compilatori siano efficienti. Riesci a immaginare di aspettare molto tempo per la compilazione perché viene utilizzato solo 1 dei tuoi 16 core? Questo è un no-go. Con tutta la teoria sembri trascurare la realtà. La pianificazione è un argomento molto interessante e molto significativo. È solo IMHO relativamente inutile nel contesto dei sistemi di compilazione. Ancora una volta, la maggior parte dei compilatori al giorno d'oggi sono comunque multithread ... e se non lo sono, lo sforzo dovrebbe piuttosto essere messo in questo piuttosto che nel sistema di compilazione della pianificazione.

— Dagnelies,

Tutti i compilatori di software gratuiti ( GCC e Clang ...) per C ++ o C o Fortran o Ada sono mono-thread. Il sistema di compilazione ( make -j) può avviare diversi processi di compilazione in parallelo.

— Basile Starynkevitch,

@BasileStarynkevitch: ... davvero. Fondamentalmente, tutti usano sano di mente, -j <nb-cores>ma purtroppo il valore predefinito è ancora "1" ... Sono ancora sorpreso che non sia mai cambiato.

— Dagnelies,

@dagnelies: esiste un numero enorme di Makefile che mancano alcune dipendenze critiche e quindi non funzionano (o potrebbero non funzionare) con -jN dove N> 1.

— juhist,