Açık kaynak buildprof derlemeleri süreç zaman çizelgelerine eşliyor ve Bun'un yavaş link adımını Full LTO'ya bağlıyor

buildprof ne yapıyor

Bir geliştirici, derleme süresinin gerçekte nereye gittiğini gösteren, Linux için açık kaynak bir izleme aracı olan buildprof'u yayınladı. Hacker News'in ana sayfasına ulaşan lalitm.com'daki blog yazısında yazar, derlemelerin genellikle düzeltilebilir nedenlerle yavaş olduğunu açıklıyor — yetersiz paralellik, tekrarlanan işler, bağımlılık indirme veya aşırı büyük bir link adımı — yoksa derlenecek çok kod olduğu için değil.

Araç, belirli bir derleme sistemiyle entegrasyon gerektirmiyor. Mevcut komutunuzun önüne ekliyorsunuz: buildprof -- make -j16, buildprof -- cargo build, buildprof -- ninja -C out/target, hatta rastgele bir depo betiği. buildprof ardından komutun başlattığı her süreci, iç içe alt süreçler dahil kaydediyor ve bunları tek bir zaman çizelgesine diziyor. Zaman soldan sağa akıyor, çubuk genişliği süreyi gösteriyor ve alt süreçler onları başlatan sürecin altında görünüyor.

Süreç ağaçları olarak görüntülenen derlemeler

Yazara göre temel fikir şu: derleme sistemleri işi birbiriyle uyumsuz terimlerle tanımlıyor — Cargo crate'lerde düşünüyor, Ninja build edge'lerde, CMake başka bir sistem için talimat üretiyor — ama işletim sistemi perspektifinden hepsi, başka süreçler başlatan süreçler olarak görünüyor. Bir Rust derlemesi cargo, rustc, cc, collect2 ve son olarak ld.lld gibi bir zincir üretebilir.

Bu katmanda görselleştirmenin üç kazanımı var: derleme sistemleri arasında özel hook'lar olmadan çalışıyor, derleme sisteminin üstündeki ve altındaki özel betikleri doğal biçimde yakalıyor ve her sürecin hangi dosyaları okuyup yazdığını kaydederek, derleme sistemi sınırlarını aşan bağımlılıkları bile açığa çıkarabiliyor.

Projeyi tetikleyen Bun vaka çalışması

Proje, Bun JavaScript runtime'ının baş mimarı Jarred Sumner'ın, Bun'un yeni Rust derlemesinin Linux'ta eski Zig derlemesinden beş kattan fazla hızlı olduğunu iddia eden bir tweet'iyle başladı. Bu, yazarın deneyimiyle çelişiyordu; benzer karmaşıklıktaki Zig projeleri genellikle daha hızlı derleniyordu.

Araştırmak için yazar, Bun 1.3.14 ve Bun 1.4.0'ın Linux x64 CI derlemelerini, derleme adımlarını ve bağımlılıklarını koruyarak 6 çekirdekli, 12 iş parçacıklı bir Linux VM'de yeniden çalıştırdı. Sayılar kabaca uyumlu çıktı: Bun'un bildirdiği CI medyanları Zig dönemi için 30d06s, Rust için 5d37s idi ve tek makinedeki yeniden çalıştırma 24d24s ile 5d40s üretti.

Tweet'te kolayca gözden kaçan bir ayrıntı: Zig derlemesi Full LTO kullanırken Rust derlemesi ThinLTO kullanıyordu. Full LTO derleme birimlerini tek büyük bir optimizasyon işinde birleştiriyor; ThinLTO daha fazla ayrım koruyarak işin büyük kısmının paralel çalışmasını sağlıyor.

İzler ne gösterdi

Zig dönemli derlemenin kaydı hemen bir darboğazı ortaya çıkardı: bir ld.lld linker çağrısı, en sona doğru tek başına on altı dakikadan uzun sürdü ve tüm derlemenin kabaca üçte ikisini oluşturdu. buildprof'un LLD'nin iç zamanlama olaylarını da katan --compiler-traces seçeneğiyle yapılan ikinci bir kayıt, bu sürenin neredeyse tamamının LTO'da geçtiğini gösterdi — linker sadece object dosyalarını birleştirmiyor, compiler pass'ları da çalıştırıyordu. Yalnızca OptModule aşaması on dakikanın biraz üzerinde sürdü ve makine kodunu üreten pass'ları içeriyor.

Buna karşılık Rust dönemli derleme, ThinLTO etkinleştirilmiş şekilde 2d24s'de link edildi. Zig derlemesinin kendi bayraklarını ThinLTO'ya çevirmek, eşleştirilmiş bir karşılaştırmada link süresini 3d40s kısalttı, ama linkleme hâlâ on üç dakikanın üzerinde sürdü. Compiler trace, adlarında JSC geçen fonksiyonlara işaret ediyordu — JavaScriptCore, yani Bun'un gömdüğü motor — ve linker'ın girdileri arasında libJavaScriptCore.a gibi WebKit kütüphaneleri vardı. Yazar, Bun'un bunları kendisinin derlemediğini buldu; ayrı bir WebKit derlemesinden indiriyordu ve o derleme de Full LTO kullanıyordu; buna karşılık Rust derlemesi, derleme tarifinde ThinLTO seçen daha yeni bir WebKit revizyonunu tüketiyordu.

Neden önemli

Bun vakası, bir dil hakkındaki hüküm olarak manşetlik bir hızlanmayı okuma konusunda yararlı bir uyarı. Yazarın izlerine göre farkın büyük kısmı, Zig derlemesinin doğası gereği yavaş olmasına değil, link zamanı optimizasyonu ayarlarına — hem Bun'un kendi linkinde hem de tükettiği önceden derlenmiş WebKit kütüphanelerinde — dayanıyordu.

Daha geniş anlamda buildprof, yavaş bir derlemesi olan her Linux geliştiricisine, sorunun paralellik mi, tekrarlanan iş mi, bağımlılık indirmeleri mi yoksa dev bir link adımı mı olduğunu, her derleme aracını ayrı ayrı instrumente etmeden görme imkanı veriyor. CI'sı onlarca dakika süren ekipler için bu görünürlük, yapılmaya değer değişikliği doğrudan gösteriyor.