Hızlandırmak mümkün mü? /Configure?

Çok sayıda CPU çekirdeğine sahip bir iş istasyonunda bir yazılım paketini derlemek için (örneğin 12), yapılandırma aşaması genellikle gerçek derleme aşamasından çok daha uzun sürer, çünkü ./configuretestler tek tek make -jçalışır gccve paralel olarak diğer komutları çalıştırır .

Kalan 11 çekirdeğin yavaşça bitmesini bekleyen boşta oturması çok büyük bir kaynak israfıdır ./configure. Testleri neden sırayla yapmak gerekiyor? Her test birbirine bağlı mı? Yanılıyor olabilirim, ancak çoğu bağımsız görünüyor.

Daha da önemlisi, hızlandırmanın bir yolu var ./configuremı?

Düzenleme: Durumu göstermek için, burada GNU Coreutils ile bir örnek

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

Sonuçlar:

# 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

İle coreutils-8.9 , ./configure6 kat daha uzun sürer make. Daha ./configureaz CPU zamanı kullanmasına rağmen ("user" ve "sys" zamanlarına bakın), paralel olmadığı için daha uzun sürer ("gerçek"). Testi birkaç kez tekrarladım (muhtemelen ilgili dosyalar bellek önbelleğinde kalıyor) ve süreler% 10 içinde.

Bu konuyla ilgili Autoconf posta listesindeki tartışmaları yaklaşık 10 yıl önce hatırlıyorum, çoğu insan yalnızca bir CPU çekirdeğine sahipken. Ama hiçbir şey yapılmadı ve hiçbir şey yapılmayacağından şüpheleniyorum. Paralel işleme için tüm bağımlılıkları ayarlamak configureve taşınabilir ve sağlam bir şekilde yapmak çok zor olurdu .

Özel senaryounuza bağlı olarak, yine de configure işlemlerini hızlandırmanın birkaç yolu olabilir. Örneğin:

• Daha hızlı bir kabuk kullanın. Örneğin, kullanmayı düşünün dashyerine basholarak /bin/sh. (Not: Altında Debian, dashböylece yamalı configurebunu kullanmaz bunu kullanarak bir sürü tatili nedeniyle, configurekomut dosyaları.)
• Derlemeleri uzaktan çalıştırırsanız (örneğin, ssh aracılığıyla), o zaman konsol çıktısının oldukça yavaş olabileceğini öğrendim. Aramayı düşünün configure -q.
• Aynı projeyi tekrar tekrar oluşturuyorsanız, önbellek dosyasını kullanmayı düşünün. Çağrı configure -C. Ayrıntılar için Autoconf belgelerine bakın.
• Çok farklı projeler inşa ediyorsanız, bir site dosyası ( config.site) kullanmayı düşünün . Yine, belgelere bakın.
• Paralel olarak birkaç proje oluşturun.

Sourcetree'nin içinde oturması için ramdrive'ı kullanmakta akıllıydınız, ancak bunu iki kez düşünün - configure ne yapar? Sadece kaynak kodunu değil , aynı zamanda çoğu zaman kütüphane, derleyiciler vb. İçin sistemi de kontrol ederek görevini yerine getirir . Bu durumda, erişim sorunu bazen disk erişiminde de olabilir. Örneğin, SSD tabanlı bir kök dosya sistemi.

Ondemand cpu valisini kullanıyorsanız, performansı kullanmaya çalışın. Bu, i7 ve a8-3850 modellerinde% 40-50 oranında yardımcı olur. Q9300 modelinde çok fazla fark yok.

Dört çekirdekli işlemci üzerinde yapabilir

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

(-R seçeneği bunu yapmalıdır, böylece her bir çekirdek için cpufreq-set yapmak zorunda kalmazsınız, ancak bilgisayarlarımda çalışmaz.)

Önbellek seçeneği olsa daha da yardımcı olur.

Pek çok ./configurekomut dosyası türü var . Bir geliştiriciye komut dosyası oluşturmada yardımcı olacak popüler araçlar ( bunlardan biri olan autconf ) ./configurevardır, ancak her geliştiricinin bu araçları kullanması gerektiğini söyleyen hiçbir kural yoktur ve sonra bu araçlar arasında bile bu komut dosyalarının biçiminde geniş değişiklikler olabilir inşa edilmiştir.

./configureParalel olarak çalıştırılabilecek herhangi bir popüler komut dosyasının farkında değilim . Popüler araçlar tarafından oluşturulan komut dosyalarının çoğu, en azından sonuçlarının bir kısmını veya tamamını önbelleğe alır, bu nedenle tekrar çalıştırırsanız ( make cleanbirincisi yapmadan ), ikinci seferde çok daha hızlı çalışır.

Bu yapılamadığını söylemedi ... ama üzerinde çalışan insanlar için çok az motivasyon olduğundan şüpheleniyorum autoconf, örneğin, bunu yapmak için, çoğu paket için yapılandırma aşaması gerçek derleme ve bağlantıya göre çok hızlıdır. fazlar.

Sabit sürücü bu durumda darboğazı. Yapıyı hızlandırmak için hızlı sürücülere sahip bir sistem üzerine kurun (okuma: düşük erişim süresi). SSD diskleriyle ilgili çok fazla yaygara var, ancak derleme zamanını olumlu yönde etkilememeleri konusunda bazı eleştiriler vardı. Yani, SSD'ye bina yapmak, iyi bir sata sürücüsünden çok daha hızlı değildi. Bu makaleyi nereden okuduğumu hatırlayamıyorum, makalenin bir kaç yaşında olması.

Neyse ... Oradan ram ve inşa etmek için Untar.

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

Sorunuz bugün daha da alakalı olabilir, çünkü biz (oldukça) düşük tek çekirdekli performansa sahip düzine çekirdekli işlemcilerimiz var. Sürekli Entegrasyon için otomatikleştirilmiş kurulumlar (CI) her işlem için çok fazla CPU zamanı / enerjisi harcar. Dalları arasında atlamalı aynı.

Yani, https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain adresindeki şeyi hızlandırmayla ilgili ipuçlarını inceleyin / okuyun .

“Testleri neden sırayla yapması gerekiyor?…” Diğerlerinin sıralı olması gerekirken aslında paralel olarak yapılabilecek birkaç şey var. Birkaç şey, derleme ortamına bağlıdır - configure betiğinin kendisi sistemden bağımsızdır. Hatta temel bilgiler içermez, bu yüzden saf bir POSIX kabuğu ile çalışır.

Taşınabilir yazılım yazmak istiyorsanız, otomatik araçlar gibi başka bir derleme sistemi yoktur. Ancak (geniş) taşınabilirliğe aldırış etmezseniz, otomatik araçlardan kaçının - hızlı ve yeterince iyi derleme araçlarının bir bolluğu vardır.