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:

Existe-t-il des systèmes de génération qui intègrent les temps de tâche attendus relatifs dans le calendrier?
Quelle recherche universitaire sur les systèmes de construction de ce type existe?
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?
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?

scheduling research build-system

— sjakobi
source

La plupart des questions concernant les ressources ou les outils tiers sont fermées rapidement en tant que "hors sujet", mais je suppose que celui-ci pourrait être un cas de pointe qui semble bien correspondre à la portée de ce site.

— Doc Brown

Je pense que cela est basé sur l'hypothèse erronée que «construire» une tâche n'est pas parallèle.

— dagnelies

Dans la plupart des cas, la construction d'une tâche est en effet non parallèle, mais oui, par exemple, les tests unitaires dans les applications multithread peuvent en effet être parallèles. En fait, dans un projet où je travaille, nous devons toujours appeler "make" avec "-j1" pour le test unitaire, car sinon les tests unitaires multicœurs liés aux performances échouent.

— juhist

@juhist Au cas où vous souhaiteriez passer à un système de construction plus expressif, shake a un concept de ressources où vous pouvez par exemple définir le nombre de cœurs de CPU à réserver pour vos tests unitaires.

— sjakobi

Réponses:

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/

— Bruno Guardia
source

Si je comprends bien votre réponse et votre lien, les temps d'action de génération sont signalés (ce qui est une caractéristique assez courante) mais il n'est pas clair si ou comment ces horaires pourraient être utilisés pour améliorer le calendrier de génération. Cela ne semble pas vraiment répondre à mes questions d'origine, donc je n'accorderai pas la prime à votre réponse.

— sjakobi

Pas de problème, ce que vous avez peut-être manqué, c'est que vous pouvez personnaliser les actions de génération et le processus de génération, grâce à la programmation. L'échantillon faisait rapport, mais comme indiqué, l'historique est pris pour les optimisations automatiques. Notez également que vous pouvez configurer des versions parallèles. Mais ensuite, pour vous assurer qu'ils sont parallélisés en suivant votre algorithme, vous devrez peut-être les personnaliser avec du code. Quelques références supplémentaires: dotnetcurry.com/visualstudio/1177/…

— Bruno Guardia

@BrunoGuardia: pouvez-vous expliquer où dans cet article de votre lien est mentionnée une option de personnalisation qui pourrait aider à utiliser les temps de tâche attendus des actions de génération?

— Doc Brown

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.

— dagnelies
source

Le parallélisme "intra-tâche" est un aspect intéressant et offre certainement un potentiel supplémentaire d'optimisation, mais je ne pense pas que supposer qu'une tâche donnée évolue efficacement vers un nombre arbitraire de CPU soit mieux que de supposer que chaque tâche doit s'exécuter sur un seul noyau.

— sjakobi

@sjakobi: eh bien, dans la pratique, il est très important que les compilateurs soient efficaces. Pouvez-vous imaginer que vous attendez longtemps pour votre compilation car un seul de vos 16 cœurs est utilisé? C'est un non. Avec toute la théorie, vous semblez ignorer la réalité. La planification est un sujet très intéressant et très significatif. C'est juste à mon humble avis relativement inutile dans le contexte des systèmes de construction. Encore une fois, la plupart des compilateurs de nos jours sont multithread de toute façon ... et s'ils ne le sont pas, il faudrait plutôt y consacrer beaucoup d'efforts plutôt que le système de construction de planification.

— dagnelies

Tous les compilateurs de logiciels libres ( GCC & Clang ...) pour C ++ ou C ou Fortran ou Ada sont mono-thread. Le système de génération ( make -j) peut lancer plusieurs processus de compilation en parallèle.

— Basile Starynkevitch

@BasileStarynkevitch: ... en effet. Fondamentalement, tout le monde utilise sain d'esprit, -j <nb-cores>mais malheureusement, la valeur par défaut est toujours "1" ... Je suis toujours surpris que cela n'ait jamais changé.

— dagnelies

@dagnelies: Il existe un grand nombre de Makefiles qui manquent certaines dépendances critiques et ne fonctionnent donc pas (ou peuvent ne pas fonctionner) avec -jN où N> 1.

— juhist