Apakah mungkin untuk mempercepat ./configure?

29

Untuk mengkompilasi paket perangkat lunak pada workstation dengan banyak core CPU (katakanlah 12), tahap konfigurasi seringkali memakan waktu lebih lama daripada tahap kompilasi yang sebenarnya karena ./configuremelakukan pengujian satu per satu, saat make -jdijalankan gccserta perintah lain secara paralel.

Saya merasa bahwa itu adalah pemborosan sumber daya yang besar untuk membiarkan 11 core yang tersisa duduk diam sebagian besar waktu menunggu yang lambat ./configureuntuk diselesaikan. Mengapa perlu melakukan tes secara berurutan? Apakah setiap tes tergantung satu sama lain? Saya bisa saja salah, tetapi sepertinya mayoritas dari mereka independen.

Lebih penting lagi, apakah ada cara untuk mempercepat ./configure?

Sunting: Untuk mengilustrasikan situasinya, berikut adalah contoh dengan 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

Hasil:

# 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

Dengan coreutils-8.9 , ./configuremembutuhkan waktu 6 kali lebih lama dari make. Meskipun ./configuremenggunakan lebih sedikit waktu CPU (lihat waktu "pengguna" & "sys"), ini membutuhkan waktu lebih lama ("nyata") karena tidak diparalelkan. Saya telah mengulangi pengujian beberapa kali (dengan file yang relevan mungkin tinggal di cache memori) dan waktunya berada dalam 10%.

— netvope
sumber

4

Ini konyol, dan memalukan, bahwa TIDAK ada alat membangun yang baik. Semua yang ada di sana murni karena inersia. Membangun binari adalah hal yang tidak dapat diprediksi.

— Matt Joiner

Itu melakukan tes berurutan karena itu akan menjadi mimpi buruk untuk mengetahui bagaimana melakukan paralelisme pada sistem tertentu yang sedang berjalan.

— Simon Richter

13

Saya ingat diskusi di milis Autoconf tentang masalah ini dari sekitar 10 tahun yang lalu, ketika kebanyakan orang sebenarnya hanya memiliki satu inti CPU. Tapi tidak ada yang dilakukan, dan saya curiga tidak ada yang dilakukan. Akan sangat sulit untuk mengatur semua dependensi untuk pemrosesan paralel configure, dan melakukannya dengan cara yang portabel dan kuat.

Tergantung pada skenario khusus Anda, mungkin ada beberapa cara untuk mempercepat proses konfigurasi. Sebagai contoh:

Gunakan shell yang lebih cepat. Misalnya, pertimbangkan untuk menggunakan dashalih-alih bashsebagai /bin/sh. (Catatan: Di bawah Debian, dashditambal sehingga configuretidak menggunakannya, karena menggunakannya merusak banyak configureskrip.)
Jika Anda menjalankan build dari jarak jauh (melalui ssh, misalnya), maka saya telah menemukan bahwa output konsol bisa sangat lambat. Pertimbangkan untuk menelepon configure -q.
Jika Anda berulang kali membangun proyek yang sama, pertimbangkan untuk menggunakan file cache. Panggil configure -C. Lihat dokumentasi Autoconf untuk detailnya.
Jika Anda membuat banyak proyek berbeda, pertimbangkan untuk menggunakan file situs ( config.site). Sekali lagi, lihat dokumentasi.
Membangun beberapa proyek secara paralel.

— Peter Eisentraut
sumber

2

Bisakah Anda jelaskan sedikit lagi mengapa makebisa diparalelkan configureatau autoconftidak?

— netvope

Sepertinya saya memiliki beberapa masalah kinerja dengan shell. Menjalankan sh -c "echo $i" > /dev/null1000 kali membutuhkan sekitar 10 detik pada sistem ini, tetapi hanya 1-2 detik pada sistem saya yang lain.

— netvope

1

GNU menggunakan kode C yang cukup rumit untuk memulai dan mengelola banyak proses. mengkonfigurasi skrip ditulis dalam shell Bourne portabel. Itu mungkin, tapi mungkin sangat sulit.

— Peter Eisentraut

4

Menyortir dependensi di antara configurepengujian sebenarnya adalah operasi dengan kompleksitas rendah (jenis topologi) dan telah dipecahkan pada awal-awal komputasi. Masalah sebenarnya adalah tidak ada yang mau repot-repot menambahkan kode ke autoconf untuk melakukannya dan fakta bahwa banyak programmer secara manual memodifikasi file yang dihasilkan. Seluruh sistem harus dirubah sehingga konfigurasi tidak lagi dilakukan oleh skrip shell tetapi biner penduduk yang membaca file data meta.

— billc.cn

1

Silakan tambahkan referensi ke diskusi yang disebutkan di milis (tautan ke arsip).

— Karl Richter

3

Anda telah pintar menggunakan ramdrive agar sourcetree berada, tetapi pikirkan dua kali - apa yang dikonfigurasikan lakukan? Itu melakukan pekerjaannya dengan memeriksa tidak hanya Anda sourcetree , tapi cukup sering juga sistem untuk ketersediaan perpustakaan, kompiler, dll Dalam hal ini, masalah akses kadang-kadang berada di akses disk - Anda akan memiliki itu dilakukan lebih cepat jika Anda memiliki untuk contoh sistem file root berbasis SSD.

— bubu
sumber

1

Sayangnya, tampaknya SSD tidak akan banyak membantu. Saya mencoba menjalankan ./configureberulang kali, tetapi proses selanjutnya hampir memakan waktu menjalankan pertama. Karena ada banyak memori bebas dalam sistem, saya pikir sistem menjalankan kompiler dan perpustakaan dari cache memori tanpa pergi ke disk.

— netvope

1

jika Anda mencoba menjalankan ./configure berulang kali (dan jika dibuat dengan autoconf) seharusnya semua hasil di-cache dan harus dilakukan dengan sangat baik. Anda dapat memposting skrip konfigurasi agar kami dapat melihatnya jika Anda ingin bantuan lebih lanjut. Saya cukup yakin ada banyak guru di sini

— bubu

Saya benar-benar membersihkannya di antara menjalankan ( ./configureselalu berjalan di pohon sumber yang baru diekstrak). Saya akan menambahkan rincian lebih lanjut di pos asli (ruang terbatas di sini).

— netvope

Saya baru saja menguji tanpa membersihkan folder (yaitu menjalankan ./configuresegera setelah yang lain ./configure) dan keduanya berjalan membutuhkan waktu yang sama. Apakah ini berarti caching tidak berfungsi mungkin pada sistem saya?

— netvope

Saya akan mengambil core dan mencoba mengkonfigurasi ketika saya punya waktu. Tetap disini.

— bubu

3

Jika Anda menggunakan gubernur cpu ondemand, coba gunakan yang kinerja. Ini membantu pada i7 dan a8-3850 sebesar 40-50%. Tidak membuat banyak perbedaan pada q9300.

Pada quad core cpu, Anda mungkin melakukannya

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

(Opsi -r harus membuatnya sehingga Anda tidak perlu melakukan cpufreq-set untuk setiap inti, tetapi di komputer saya itu tidak berfungsi.)

Opsi cache bahkan lebih membantu.

— Dan Kegel
sumber

3

Ada banyak jenis ./configureskrip. Ada alat-alat populer ( autconf menjadi salah satunya) untuk membantu pengembang dalam membuat ./configureskrip, tetapi tidak ada aturan yang mengatakan setiap pengembang harus menggunakan alat ini, dan bahkan di antara alat-alat ini, dapat ada variasi yang luas dalam cara skrip ini dibangun.

Saya tidak mengetahui adanya ./configureskrip populer yang dapat dijalankan secara paralel. Sebagian besar skrip yang dibuat oleh alat-alat populer setidaknya melakukan cache beberapa atau semua hasil mereka, jadi jika Anda menjalankannya lagi (tanpa melakukan yang make cleanpertama, bagaimanapun), itu berjalan lebih cepat untuk yang kedua kalinya.

Itu bukan untuk mengatakan itu tidak dapat dilakukan ... tapi saya curiga ada sedikit motivasi bagi orang yang bekerja autoconf, misalnya, untuk melakukan itu, karena untuk sebagian besar paket, tahap konfigurasi sangat cepat relatif terhadap kompilasi aktual dan menghubungkan fase.

— Flimzy
sumber

2

Ada alasan bagus untuk menggunakan alat ini: mereka sudah matang, dan mereka melacak banyak detail kecil. Saya pikir Linux tidak akan berada dalam posisi yang hebat di dunia tertanam jika Anda tidak bisa begitu saja mengarahkan skrip configure ke kompiler silang Anda dan membuatnya bekerja di luar kotak 90% dari waktu.

— Simon Richter

2

Hard drive adalah hambatan dalam hal ini. Untuk mempercepat pembangunan, bangun sistem dengan drive cepat (baca: waktu akses rendah). Ada banyak keributan tentang cakram SSD, tetapi ada beberapa kritik mengenai mereka yang tidak mempengaruhi waktu kompilasi secara positif. Artinya membangun SSD tidak jauh lebih cepat daripada pada drive sata yang layak. Saya tidak ingat di mana saya membaca ini karena artikel ini berumur beberapa tahun.

Ngomong-ngomong ... Untar untuk ram dan membangun dari sana.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

— Ярослав Рахматуллин
sumber

1

Terima kasih, tapi saya sudah mengkompilasi / dev / shm yang merupakan tmpfs :-)

— netvope

0

Pertanyaan Anda bahkan mungkin lebih relevan hari ini karena kami memiliki selusin-inti CPU dengan (kinerja) inti tunggal yang rendah. Build otomatis untuk Continuous Integration (CI) benar-benar membuang banyak waktu CPU / energi untuk setiap komit. Sama dengan melompat antar cabang.

Jadi tinjau / baca petunjuk saya tentang mempercepat hal itu di https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

"Mengapa perlu melakukan tes secara berurutan? ..." Sebenarnya ada beberapa hal yang dapat dilakukan secara paralel, sementara yang lain harus berurutan. Beberapa hal tergantung pada lingkungan build - dan skrip configure itu sendiri adalah sistem independen. Bahkan tidak mengandung bashism, jadi ia bekerja dengan shell POSIX murni.

Jika Anda ingin menulis perangkat lunak portabel, tidak ada sistem build lain seperti autotools. Tetapi jika Anda tidak keberatan dengan portabilitas (lebar), hindari autotool - ada banyak alat pembuatan yang cepat dan cukup bagus.

— Sepatu bot Tim Ruehsen
sumber