Oto mała ilustracja mojego pytania:
Załóżmy zadanie kompilacji, które składa się z 4 niezależnych zadań o nazwie AD. D w sumie trwa dłużej niż AC.
System kompilacji, który nie może uwzględnić względnych czasów zadań, może zaplanować takie zadania:
---------------------------------------
CPU1: A | C |
---------------------------------------
CPU2: B | D |
---------------------------------------
W przeciwieństwie do tego, jeśli program planujący zdaje sobie sprawę z różnic czasu między zadaniami, może zaproponować znacznie krótszy harmonogram:
---------------------------------------
CPU1: A | B | C |
---------------------------------------
CPU2: D |
---------------------------------------
Moje pytania:
- Czy są jakieś systemy kompilacji uwzględniające w harmonogramie względne oczekiwane czasy zadań?
- Jakie istnieją badania naukowe dotyczące tego rodzaju systemów kompilacji?
- Skąd te systemy kompilacji (jeśli istnieją) pobierają informacje o czasie? Heurystyka, czasy zebrane podczas poprzednich kompilacji?
- Jeśli takie systemy kompilacji nie istnieją, dlaczego? Czy istnieje gotcha, która sprawiłaby, że byłyby mniej wartościowe niż się wydaje na pierwszy rzut oka?
scheduling
research
build-system
sjakobi
źródło
źródło
Odpowiedzi:
Microsoft Visual Studio Team System (wcześniej TFS) bierze pod uwagę czasy akcji kompilacji i kompilacje równoległe; pobiera dane z poprzedniej historii kompilacji; i chociaż nie wierzę, że możesz uzyskać pożądane zachowanie po wyjęciu z pudełka, możesz być w stanie go dostosować.
Przykład niektórych niestandardowych zadań do pracy nad optymalizacją wydajności
https://veegens.wordpress.com/2013/03/26/tfs-2010-build-performance-report/
źródło
Opiera się to na błędnym założeniu, że „budowanie” zadania nie jest równoległe.
Wiele kompilatorów działa wielowątkowo, więc jedno zadanie A będzie wykorzystywać wszystkie procesory. Dlatego kolejność nie ma znaczenia. W przypadku zadań związanych z operacjami we / wy, zwłaszcza związanych z tworzeniem sieci, lepiej rozpocząć je wszystkie równolegle od samego początku: większość czasu będzie poświęcana na oczekiwanie na odpowiedź.
Innymi słowy, kolejność nie ma znaczenia, ponieważ poszczególne zadania są zwykle równoległe (jak na przykład kompilacja)
Edytować:
W rzeczywistości ta koncepcja „Zadania A na CPU 1” jest również wadliwa. Nawet w przypadku zadań jednowątkowych system operacyjny planujący procesy / wątki może przeskakiwać z procesora na procesor na każdym przełączniku kontekstowym. Wydaje mi się, że większość systemów kompilacji po prostu uruchamia wszystkie zadania równolegle i pozwala systemowi operacyjnemu wykonać harmonogram. Dłuższe zadania potrwają dłużej i tyle.
Zakładając, że masz długo działające jedno wątkowe zadanie, które nie jest związane z operacjami we / wy , systemowi kompilacji byłoby znacznie łatwiej przypisać mu priorytet / ważność, zamiast próbować opóźniać mniejsze zadania w celu ograniczenia przełączania kontekstu z systemu operacyjnego.
Nawet jeśli masz tak dziwne zadania, co jest dość rzadkie w praktyce, i masz fantazyjny system kompilowania harmonogramów, który działa na heurystyce w oparciu o poprzednie przebiegi (jedyny sposób, aby się dowiedzieć), korzyści, które możesz z tego uzyskać, mogą być niewielkie. . jednak masz do czynienia z dodatkową złożonością.
źródło
make -j
Kompilacja system ( ) może równolegle uruchamiać kilka procesów kompilacji.-j <nb-cores>
ale niestety domyślną wartością jest wciąż „1” ... Nadal jestem zaskoczony, że nigdy się nie zmieniła.