Gibt es Buildsysteme, die die relativ zu erwartenden Taskzeiten in den Zeitplan einbeziehen?

Hier ist eine kleine Illustration meiner Frage:

Nehmen Sie einen Build-Job an, der aus 4 unabhängigen Tasks mit dem Namen AD besteht. D dauert länger als AC.

Ein Build-System, das die relativen Task-Zeiten nicht berücksichtigen kann, plant die Tasks möglicherweise folgendermaßen:

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

Wenn der Scheduler hingegen die Zeitunterschiede der Aufgabe kennt, könnte er sich diesen viel kürzeren Zeitplan einfallen lassen:

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

Meine Fragen:

Gibt es Buildsysteme, die die relativ zu erwartenden Taskzeiten in den Zeitplan einbeziehen?
Welche akademische Forschung zu solchen Buildsystemen gibt es?
Woher beziehen diese Build-Systeme (falls vorhanden) die Zeitinformationen? Heuristiken, Timings aus früheren Builds?
Wenn solche Build-Systeme nicht existieren, warum? Gibt es eine GOTCHA, die sie weniger wert macht, als sie auf den ersten Blick erscheinen?

scheduling research build-system

— sjakobi
quelle

Die meisten Fragen zu Ressourcen oder Tools von Drittanbietern werden schnell als "Off-Topic" geschlossen, aber ich denke, dies könnte ein Randfall sein, der gut zum Umfang dieser Website zu passen scheint.

— Doc Brown

Ich denke, dies basiert auf der falschen Annahme, dass das "Bauen" einer Aufgabe nicht parallel ist.

— dagnelies

In den meisten Fällen ist das Erstellen einer Aufgabe zwar nicht parallel, aber ja, z. B. können Komponententests in Multithread-Anwendungen tatsächlich parallel sein. Tatsächlich müssen wir in einem Projekt, in dem ich arbeite, für den Unit-Testlauf immer "make" mit "-j1" aufrufen, da ansonsten leistungsbezogene Multicore-Unit-Tests fehlschlagen.

— JUHIST

@juhist Für den Fall, dass Sie zu einem aussagekräftigeren Build-System wechseln möchten, hat shake ein Ressourcenkonzept, in dem Sie beispielsweise festlegen können, wie viele CPU-Kerne für Ihre Komponententests reserviert werden sollen.

— sjakobi

Antworten:

Microsoft Visual Studio Team System (ehemals TFS) berücksichtigt Build-Aktionszeiten und parallele Builds. Es übernimmt die Daten aus dem vorherigen Build-Verlauf. und obwohl ich nicht glaube, dass Sie das gewünschte Verhalten sofort erreichen können, können Sie es möglicherweise anpassen.

Ein Beispiel für einige benutzerdefinierte Aufgaben zur Optimierung der Leistung

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

— Bruno Guardia
quelle

Wenn ich Ihre Antwort und Ihren Link richtig verstehe, werden Build-Aktionszeiten gemeldet (was ziemlich häufig vorkommt), aber es ist nicht klar, ob oder wie diese Timings zur Verbesserung des Build-Zeitplans verwendet werden könnten. Dies scheint meine ursprüngliche (n) Frage (n) nicht wirklich zu beantworten, so dass ich Ihre Antwort nicht mit dem Kopfgeld belohnen werde.

— sjakobi

Kein Problem, was Sie möglicherweise übersehen haben, ist, dass Sie Build-Aktionen und den Build-Prozess durch Programmierung anpassen können. Die Stichprobe wurde gemeldet, aber wie angegeben wird der Verlauf für automatische Optimierungen verwendet. Beachten Sie auch, dass Sie parallele Builds konfigurieren können. Um sicherzustellen, dass sie gemäß Ihrem Algorithmus parallelisiert sind, müssen Sie sie möglicherweise mit Code anpassen. Einige zusätzliche Hinweise: dotnetcurry.com/visualstudio/1177/…

— Bruno Guardia

@BrunoGuardia: Können Sie erklären, wo in diesem Artikel Ihres Links eine Anpassungsoption erwähnt ist, die dazu beitragen kann, die erwarteten Taskzeiten der Build-Aktionen zu nutzen?

— Doc Brown

Dies basiert auf der falschen Annahme, dass das "Erstellen" einer Aufgabe nicht parallel ist.

Viele Compiler arbeiten mit mehreren Threads, sodass eine einzelne Task A alle CPUs verwendet. Daher spielt die Reihenfolge keine Rolle. Bei E / A-gebundenen Aufgaben, insbesondere bei Netzwerkaufgaben, sollten Sie diese auch parallel starten: Die meiste Zeit wird darauf verwendet, auf eine Antwort zu warten.

Mit anderen Worten, die Reihenfolge spielt keine Rolle, da die einzelnen Aufgaben typischerweise parallelisiert werden (wie zum Beispiel das Kompilieren).

Bearbeiten:

Tatsächlich ist auch diese Konzeption von "Task A auf CPU 1" fehlerhaft. Selbst für Single-Thread-Aufgaben kann das Betriebssystem, das die Prozesse / Threads plant, bei jedem Kontextwechsel von CPU zu CPU springen. Ich vermute, die meisten Build-Systeme führen alle Aufgaben nur parallel aus und lassen das Betriebssystem die Zeitplanung durchführen. Längere Aufgaben werden länger dauern und das wars auch schon.

Angenommen, Sie haben eine Single-Thread-Task mit langer Laufzeit, die nicht an E / A gebunden ist , ist es für das Build-System viel einfacher, eine Priorität / Wichtigkeit zuzuweisen, als zu versuchen, kleinere Tasks zu verzögern, um Kontextwechsel vom Betriebssystem zu reduzieren.

Selbst wenn Sie solch seltsame Aufgaben haben, die in der Praxis recht selten sind, und ein ausgefallenes Planungssystem haben, das auf Heuristiken basiert, die auf früheren Läufen basieren (die einzige Möglichkeit, dies zu wissen), sind die Vorteile, die Sie daraus ziehen, möglicherweise eher gering. .jedoch Sie erhalten eine Reihe von zusätzlichen Komplexität zu pflegen.

— dagnelies
quelle

"Within-Task" -Parallelität ist ein interessanter Aspekt und bietet sicherlich zusätzliches Optimierungspotenzial, aber ich denke nicht, dass die Annahme, dass eine bestimmte Task effizient auf eine beliebige Anzahl von CPUs skaliert werden kann, besser ist als die Annahme, dass jede Task ausgeführt werden muss ein einzelner Kern.

— sjakobi

@sjakobi: Nun, in der Praxis ist es ziemlich wichtig, dass Compiler effizient sind. Können Sie sich vorstellen, dass Sie lange auf Ihr Kompilieren warten, weil nur 1 Ihrer 16 Kerne verwendet wird? Das ist ein No-Go. Bei aller Theorie scheint man die Realität zu übersehen. Die Terminplanung ist ein sehr interessantes und aussagekräftiges Thema. Es ist nur meiner Meinung nach im Zusammenhang mit Build-Systemen relativ nutzlos. Wiederum sind die meisten Compiler heutzutage sowieso Multithread-fähig ... und wenn dies nicht der Fall ist, sollte viel mehr Aufwand in das Scheduling-Build-System gesteckt werden.

— dagnelies

Alle freien Software-Compiler ( GCC & Clang ...) für C ++ oder C oder Fortran oder Ada sind Monothread- Compiler . Das Build-System ( make -j) kann mehrere Kompilierungsprozesse gleichzeitig starten.

— Basile Starynkevitch

@BasileStarynkevitch: ... in der Tat. Grundsätzlich verwendet jeder vernünftig, -j <nb-cores>aber leider ist die Standardeinstellung immer noch "1" ... Ich bin immer noch überrascht, dass es sich nie geändert hat.

— dagnelies

@dagnelies: Es gibt eine große Anzahl von Makefiles, die einige kritische Abhängigkeiten übersehen und daher nicht mit -jN funktionieren (oder möglicherweise nicht funktionieren), wobei N> 1 ist.

— Freitag,