Czy można przyspieszyć ./configure?

29

Aby skompilować pakiet oprogramowania na stacji roboczej z wieloma rdzeniami procesora (powiedzmy 12), etap konfiguracji często trwa znacznie dłużej niż faktyczny etap kompilacji, ponieważ ./configuretesty są wykonywane jeden po drugim, podczas gdy są make -juruchamiane, gcca także inne polecenia równolegle.

Uważam, że marnowanie zasobów jest ogromnym marnotrawstwem, ponieważ pozostałe 11 rdzeni pozostaje bezczynnie przez większość czasu i czeka na zakończenie spowolnienia ./configure. Dlaczego musi przeprowadzać testy sekwencyjnie? Czy każdy test zależy od siebie? Mogę się mylić, ale wygląda na to, że większość z nich jest niezależna.

Co ważniejsze, czy są jakieś sposoby na przyspieszenie ./configure?


Edycja: Aby zilustrować sytuację, oto przykład z GNU Coreutils

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

Wyniki:

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

Z Coreutils-8,9 , ./configuretrwa dłużej niż 6 razy make. Chociaż ./configurezużywa mniej czasu procesora (patrz czasy „użytkownik” i „sys”), zajmuje dużo więcej czasu („rzeczywisty”), ponieważ nie jest równoległy. Powtórzyłem test kilka razy (z odpowiednimi plikami prawdopodobnie pozostają w pamięci podręcznej pamięci), a czasy mieszczą się w granicach 10%.

netvope
źródło
4
To niedorzeczne i szkoda, że ​​NIE MA dobrych narzędzi do budowania. Wszystkie te, które istnieją, są spowodowane wyłącznie bezwładnością. Budowanie binariów to taka dziwna, nieprzewidywalna rzecz.
Matt Joiner,
Testy wykonuje się sekwencyjnie, ponieważ koszmarem byłoby dowiedzieć się, jak wykonać równoległość w systemie, na którym działa.
Simon Richter

Odpowiedzi:

13

Przypominam sobie dyskusje na liście mailingowej Autoconf na ten temat sprzed około 10 lat, kiedy większość ludzi miała tylko jeden rdzeń procesora. Ale nic nie zostało zrobione i podejrzewam, że nic nie zostanie zrobione. Bardzo trudno byłoby skonfigurować wszystkie zależności dla przetwarzania równoległego configurei zrobić to w sposób przenośny i niezawodny.

W zależności od konkretnego scenariusza może istnieć kilka sposobów na przyspieszenie konfiguracji. Na przykład:

  • Użyj szybszej powłoki. Na przykład rozważ użycie dashzamiast bashas /bin/sh. (Uwaga: pod Debianem dashjest załatany, więc configurego nie używa, ponieważ używanie go psuje wiele configureskryptów.)
  • Jeśli uruchamiasz kompilacje zdalnie (na przykład przez ssh), to odkryłem, że wyjście konsoli może być dość wolne. Rozważ dzwonienie configure -q.
  • Jeśli wielokrotnie budujesz ten sam projekt, rozważ użycie pliku pamięci podręcznej. Zadzwoń configure -C. Szczegółowe informacje można znaleźć w dokumentacji Autoconf.
  • Jeśli budujesz wiele różnych projektów, rozważ użycie pliku witryny ( config.site). Ponownie zobacz dokumentację.
  • Zbuduj kilka projektów równolegle.
Peter Eisentraut
źródło
2
Czy mógłbyś wyjaśnić nieco więcej, dlaczego makemożna je zrównoleglać, ale configureczy autoconfnie?
netvope,
Wygląda na to, że mam pewne problemy z wydajnością powłoki. Uruchamianie sh -c "echo $i" > /dev/null1000 razy zajmuje około 10 sekund w tym systemie, ale tylko 1-2 sekund w innych systemach.
netvope,
1
GNU make używa dość skomplikowanego kodu C do uruchamiania i zarządzania wieloma procesami. skrypty konfiguracyjne są napisane w przenośnej powłoce Bourne'a. Byłoby to możliwe, ale prawdopodobnie bardzo trudne.
Peter Eisentraut,
4
Sortowanie zależności między configuretestami jest w rzeczywistości operacją o niskiej złożoności (sortowanie topologiczne) i zostało rozwiązane we wczesnych dniach obliczeń. Prawdziwy problem polega na tym, że nikt nie zadał sobie trudu dodania kodu do autoconf, aby to zrobić, oraz fakt, że wielu programistów ręcznie modyfikuje wygenerowane pliki. Cały system powinien zostać odnowiony, aby konfiguracja nie była już wykonywana przez skrypt powłoki, ale rezydentny plik binarny odczytujący pliki metadanych.
billc.cn
1
Dodaj odniesienie do wspomnianej dyskusji na liście mailingowej (link do archiwum).
Karl Richter
3

Jesteś mądry w używaniu napędu ramdrive, aby mieć siedzibę w źródle, ale zastanów się dwa razy - co robi konfiguracja? Robi to, sprawdzając nie tylko twoje źródło , ale często także system dostępności bibliotek, kompilatorów itp. W takim przypadku problem z dostępem czasami dotyczy dostępu do dysku - będziesz musiał zrobić to znacznie szybciej, jeśli masz na przykład główny system plików oparty na SSD.

bubu
źródło
1
Niestety wydaje się, że dyski SSD niewiele pomogą. Próbowałem biegać ./configurewielokrotnie, ale kolejne biegi trwają prawie tak długo, jak pierwszy bieg. Ponieważ w systemie jest dużo wolnej pamięci, myślę, że system uruchamia kompilatory i biblioteki z pamięci podręcznej bez przechodzenia na dysk.
netvope,
1
jeśli próbujesz wielokrotnie uruchamiać ./configure (i jeśli jest zrobiony przez autoconf), powinien mieć wszystkie wyniki w pamięci podręcznej i powinien działać bardzo dobrze. Możesz opublikować skrypt konfiguracyjny, abyśmy mogli sprawdzić, czy potrzebujesz dodatkowej pomocy. Jestem całkiem pewien, że jest tu mnóstwo guru
bubu
Naprawdę wyczyściłem go między uruchomieniami ( ./configurezawsze działa w świeżo wyodrębnionym drzewie źródłowym). Zamierzam dodać więcej szczegółów w oryginalnym poście (tutaj jest mało miejsca).
netvope,
Właśnie przetestowałem bez czyszczenia folderu (tj. Uruchamianie ./configurenatychmiast po drugim ./configure), a dwa przebiegi zajmują tyle samo czasu. Czy to znaczy, że buforowanie prawdopodobnie nie działa w moim systemie?
netvope,
Wezmę coreutils i spróbuję skonfigurować, kiedy będę miał czas. Bądźcie czujni.
bubu
3

Jeśli używasz gubernatora procesora ondemand, spróbuj użyć wydajnego. Pomaga to na i7 i a8-3850 o 40-50%. Q9300 nie robi dużej różnicy.

Na czterordzeniowych procesorach możesz to zrobić

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

(Opcja -r powinna sprawić, że nie będziesz musiał robić cpufreq-set dla każdego rdzenia, ale na moich komputerach to nie działa.)

Opcja pamięci podręcznej pomaga jednak jeszcze bardziej.

Dan Kegel
źródło
3

Istnieje wiele rodzajów ./configureskryptów. Istnieją popularne narzędzia ( jednym z nich jest autconf), które pomagają programistom w tworzeniu ./configureskryptu, ale nie ma reguły, która mówi, że każdy programista musi korzystać z tych narzędzi, a nawet między tymi narzędziami mogą istnieć szerokie różnice w sposobie działania tych skryptów są zbudowane.

Nie znam żadnych popularnych ./configureskryptów, które można uruchomić równolegle. Większość skryptów zbudowanych przez popularne narzędzia przynajmniej buforuje niektóre lub wszystkie ich wyniki, więc jeśli uruchomisz je ponownie (bez zrobienia make cleanpierwszego, zresztą), uruchomi się znacznie szybciej za drugim razem.

Nie oznacza to, że nie można tego zrobić ... ale podejrzewam, że ludzie mają na to małą motywację autoconf, na przykład, aby to zrobić, ponieważ w przypadku większości pakietów faza konfiguracji jest bardzo szybka w stosunku do faktycznej kompilacji i łączenia fazy

Flimzy
źródło
2
Istnieje jednak dobry powód, aby korzystać z tych narzędzi: są one dojrzałe i śledzą wiele drobnych szczegółów. Myślę, że Linux nie byłby w tak świetnej sytuacji we wbudowanym świecie, gdybyś nie mógł po prostu skierować skryptu konfiguracyjnego na swój kompilator krzyżowy i pozwolić mu pracować przez 90% czasu.
Simon Richter
2

Dysk twardy jest w tym przypadku wąskim gardłem. Aby przyspieszyć kompilację, zbuduj system z szybkimi dyskami (czytaj: krótki czas dostępu). Dyski SSD są bardzo zamieszane, ale pojawiła się krytyka, że ​​nie wpłynęły one pozytywnie na czas kompilacji. To znaczy, że budowanie na SSD nie było o wiele szybsze niż na porządnym dysku sata. Nie pamiętam, gdzie to przeczytałem, bo artykuł ma kilka lat.

W każdym razie ... Untar taranować i budować stamtąd.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2
Ярослав Рахматуллин
źródło
1
Dzięki, ale już kompilowałem / dev / shm, który jest tmpfs :-)
netvope
0

Twoje pytanie może być jeszcze bardziej aktualne, ponieważ mamy kilkanaście rdzeni procesorów o (ładnej) niskiej wydajności pojedynczego rdzenia. Automatyczne kompilacje dla Continuous Integration (CI) naprawdę marnują dużo czasu procesora / energii dla każdego zatwierdzenia. To samo dotyczy przeskakiwania między gałęziami.

Więc przejrzyj / przeczytaj moje wskazówki dotyczące przyspieszenia rzeczy na https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increase-speed-of-GNU-toolchain .

„Dlaczego musi przeprowadzać testy sekwencyjnie? ...” W rzeczywistości istnieje kilka rzeczy, które można zrobić równolegle, podczas gdy inne muszą być sekwencyjne. Kilka rzeczy zależy od środowiska kompilacji - a sam skrypt konfiguracyjny jest niezależny od systemu. Nie zawiera nawet bashism, więc działa z czystą powłoką POSIX.

Jeśli chcesz pisać przenośne oprogramowanie, nie ma innego systemu kompilacji, takiego jak narzędzia automatyczne. Ale jeśli nie przeszkadza ci (szeroka) przenośność, unikaj autotoolów - istnieje mnóstwo szybkich i wystarczająco dobrych narzędzi do budowania.

Tim Ruehsen rockdaboot
źródło