Existe-t-il des systèmes de génération qui intègrent les temps de tâche attendus relatifs dans le calendrier?

Voici une petite illustration de ma question:

Supposons un travail de génération composé de 4 tâches indépendantes nommées AD. D prend plus de temps que AC en somme.

Un système de génération qui ne peut pas incorporer les temps de tâche relatifs peut planifier les tâches comme ceci:

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

En revanche, si le planificateur est conscient des différences de temps de tâche, il pourrait arriver avec ce calendrier beaucoup plus court:

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

Mes questions:

1. Existe-t-il des systèmes de génération qui intègrent les temps de tâche attendus relatifs dans le calendrier?
2. Quelle recherche universitaire sur les systèmes de construction de ce type existe?
3. D'où ces systèmes de construction (s'ils existent) prennent-ils les informations de temps? Heuristique, timings collectés lors des builds précédents?
4. Si de tels systèmes de construction n'existent pas, pourquoi? Y a-t-il un piège qui les rendrait moins dignes de ce qu'ils semblent à première vue?

Microsoft Visual Studio Team System (anciennement TFS) prend en compte les temps d'action de génération et les générations parallèles; il prend les données de l'historique de génération précédent; et même si je ne pense pas que vous puissiez obtenir le comportement que vous souhaitez, vous pouvez peut-être le personnaliser.

Un exemple de certaines tâches personnalisées pour optimiser les performances

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

Ceci est basé sur l'hypothèse erronée que la «construction» d'une tâche n'est pas parallèle.

De nombreux compilateurs fonctionnent sur plusieurs threads, donc une seule tâche A utilisera tous les CPU. Par conséquent, l'ordre n'a pas d'importance. Pour les tâches liées aux E / S, notamment celles liées à la mise en réseau, il vaut mieux les démarrer toutes en parallèle également depuis le début: la plupart du temps sera consacré à attendre une réponse.

En d'autres termes, l'ordre n'a pas d'importance car les tâches individuelles sont généralement parallélisées (comme la compilation par exemple)

Éditer:

En fait, cette conception de la "Tâche A sur le CPU 1" est également imparfaite. Même pour les tâches à thread unique, le système d'exploitation qui planifie les processus / threads peut l'espérer de CPU en CPU à chaque changement de contexte. Je suppose que la plupart des systèmes de construction exécuteront simplement toutes les tâches en parallèle et laisseront le système d'exploitation faire la planification. Les tâches plus longues prendront plus de temps et c'est tout.

En supposant que vous ayez une tâche à thread unique de longue durée qui n'est pas liée aux E / S , il serait beaucoup plus facile pour le système de génération de lui attribuer une priorité / importance plutôt que de tenter de retarder des tâches plus petites pour réduire les changements de contexte du système d'exploitation.

Même si vous avez des tâches aussi étranges , ce qui est assez rare dans la pratique, et avez un système de construction de planification sophistiqué qui fonctionne sur des heuristiques basées sur des exécutions précédentes (la seule façon de le savoir), les avantages que vous en retirez peuvent être plutôt faibles. .toutefois, vous obtenez un tas de complexité supplémentaire à maintenir.