Czy można przyspieszyć ./configure?

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%.

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.

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.

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.

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

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

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.