Zig derleme hızı artıyor
(mitchellh.com)- Zig 0.15.1 sürümünün çıkmasıyla derleme hızı, önceki sürüme kıyasla belirgin biçimde iyileşti
- Ghostty projesi üzerinde yapılan gerçek derleme süresi ölçümlerine göre genel olarak çalışma süresi kısaldı
- Hâlâ kısmen LLVM kullanılıyor olsa da, kendi backend’inin uygulanmasıyla ek hız artışı beklentisi yüksek
- Artımlı derleme (incremental compilation) henüz tamamen uygulanmış değil, ancak kısmi derlemelerde de performans avantajı görülüyor
- Gelecekte daha da hızlı bir derleme ortamı ve iyileştirilmiş geliştirici deneyimi sağlanması olasılığı yüksek
Genel Bakış
Andrew Kelley’nin "derleyici çok yavaş olduğu için hata oluşuyor" sözüyle başlayan süreçte Zig, yıllardır daha hızlı derleme süreleri hedefiyle çeşitli yapısal iyileştirmeler üzerinde çalıştı
- Zig ekibi LLVM’yi kaldırma, kendi kod üretim backend’ini geliştirme, bağımsız bir linker oluşturma ve nihayetinde artımlı derlemeyi hayata geçirme yönünde çalışıyor
- Bu uzun vadeli geliştirmenin sonuçları Zig 0.15.1 sürümünde görünür hâle gelmeye başladı ve gerçek bir projede (Ghostty) derleme sürelerindeki değişim ölçülerek paylaşıldı
Build Script derleme hızı
- Zig 0.14: 7 saniye 167 ms
- Zig 0.15: 1 saniye 702 ms
Bu, build.zig betiğinin kendi derleme süresi; yani yeni bir kaynak derleme ortamında her seferinde katlanılan başlangıç maliyeti
- Build script’in yeniden derlenme sıklığı düşük tutulsa da, kullanıcının projeyi ilk kez kendi başına derleme deneyimini doğrudan etkiliyor
Tam önbelleksiz binary derlemesi (Ghostty)
- Zig 0.14: 41 saniye
- Zig 0.15: 32 saniye
Bu, build script derleme süresi de dâhil olmak üzere tüm binary derleme süresi
- Zig 0.15 ile yaklaşık 2 saniyelik ek hız iyileşmesi var ve gerçek duvar saati süresi açısından da belirgin bir ilk fark görülüyor
- Kendi x86_64 backend’i henüz tam olarak kullanılamıyor ve büyük ölçüde LLVM kullanılmaya devam ediliyor
- İleride Ghostty tamamen kendi backend’i ile derlendiğinde sürenin 25 saniyenin altına düşeceği tahmin ediliyor (önceye göre yaklaşık yarı yarıya)
Artımlı derleme (Ghostty çalıştırılabilir dosyası)
- Zig 0.14: 19 saniye
- Zig 0.15: 16 saniye
Anlamlı tek satırlık bir değişiklikten sonra (terminal emülasyonu koduna bir log çağrısı eklenmesi) yeniden derleme için gereken süre
- Build script ve bağımlılık grafiği zaten önbellekteyken yapılan kısmi derleme
- Artımlı derleme özelliği henüz kusursuz şekilde tamamlanmış olmasa da, performans iyileşmesi şimdiden açıkça görülüyor
- Kullanımdaki LLVM devreden çıkarıldığında sürenin yaklaşık 12 saniyeye inme potansiyeli var
- İleride gerçek artımlı derleme hayata geçtiğinde, milisaniye düzeyinde derleme süreleri bile mümkün olabilir
Artımlı derleme (libghostty-vt)
- Zig 0.14: 2 saniye 884 ms
- Zig 0.15: 975 ms
Tek satırlık bir değişiklikten sonra yalnızca libghostty-vt için yapılan kısmi yeniden derleme süresi ölçümü
libghostty-vt, kendi x86_64 backend’i ile tamamen derlenebildiği için LLVM etkisi olmadan Zig’deki iyileştirmeler doğrudan yansıyor- Artımlı derleme olmasa bile 1 saniyenin altında derleme süresine ulaşılması önemli bir ilerleme
- Geliştirici iş akışında anında geri bildirim deneyimi sağlayarak verimliliği artırıyor
- x86_64 ve aarch64 backend’leri giderek daha kararlı hâle geliyor ve birkaç ay içinde Ghostty’nin tamamına uygulanma ihtimali bulunuyor
Derleme hızı iyileştirmelerinde mevcut durum
- Ghostty derlemesi, Zig 0.15.1 kullanıldığında tüm ölçüm noktalarında açık biçimde daha hızlı
- Kendi backend’i ve artımlı derleme henüz tamamlanmamış olsa da, mevcut sonuçlar tek başına bile oldukça etkileyici
- Önümüzdeki 1-2 yıl içinde çok daha çarpıcı hız iyileştirmeleri bekleniyor
- Zig’i seçmenin derleme hızı açısından mantıklı bir tercih olduğu daha net hissediliyor
1 yorum
Hacker News görüşleri
1995'te liseden mezun olurken Intel 486 üzerinde "Borland Pascal version Turbo Vision for DOS"u yeniden derlediğim zamanki hızla yarışacak kadar hızlı derleme süreleri artık gerçekten mümkün
Turbo Vision, Borland Pascal ve C++ IDE geliştirmede kullanılan bir TUI pencere çerçevesiydi
Bunu, JetBrains IDE'nin 1000MB yerine 10MB'lık karakter modu sürümü gibi düşünebilirsiniz
Turbo Vision Vikipedi
LLVM bir tür tuzak
Bootstrap aşaması gerçekten hızlı ve bir sürü optimizasyon geçidiyle çeşitli platform desteğini bedavaya alıyorsunuz, ama son optimizasyon ya da linkleme aşamasının performansını ince ayarlama becerisini kaybediyorsunuz
Cranelift'in yakında Rust'ta etkinleşeceğini düşünüyorum
Ama Rust'ın başlangıçta LLVM'yi seçmiş olması, bugünkü konumuna gelmesinde büyük rol oynadı
Go ise kod üretimini ve linklemeyi dışarıya bırakmayıp kendi içinde yönetmeye çok önceden karar verdi ve bunun faydasını fazlasıyla görüyor
LLVM'nin tuzak olduğu iddiasına katılmak zor, bence Rust tam tersine iyi bir örnek
Gerçekte LLVM ile kod üretimi derleyicinin çok küçük bir bölümünü oluşturuyor ve değiştirmek isterseniz codegen_cranelift ya da codegen_gcc ile bunu yapabilirsiniz
SIMD vendor intrinsic bağımlılığı bir "lock-in" sorunu olabilir ama bu dil yapısının sorunu
Çoğu dil için LLVM backend ile başlamak mantıklı
C/C++ benzeri dillerde yalnızca LLVM'nin varsayılan pipeline'ı bile iyi optimizasyon verirken, özellikleri farklı dillerde genelde özel optimizasyon pipeline'ları yazılır
Go'nun baştan beri kendi backend'ini entegre etmiş olması başarılı görünüyor ama bu başlı başına özel bir farklılaştırıcı değil ve bunu kendiniz geliştirmenin fırsat maliyeti oldukça yüksek
Go ve Ocaml derleyicileri gerçekten çok hızlı
Kendi kütüphanelerini baştan düzgün kurdular ve artık hız açısından kaybedecekleri pek bir şey yok
Gelecekte 1 dakikadan uzun süren derleme ortamlarında çalışmak istemiyorum
Her proje için bir "dev" derleyicisi olsa ve yalnızca son build'de llvm gibi ağır bir şey kullanılsa keşke
LLVM tabanlı bir dil C++'ın yerini almayı hedefliyorsa, yine de C++'a bağımlı kalıyor
Bir dil kendi kendini bootstrap edebilmelidir
Başlangıçta kullanışlı araçlar vardır ama bunlar sadece zaman kazandırır, vazgeçilmez değildir
Go ekibinin verdiği karara tamamen katılıyorum
Cranelift'in istikrarlı biçimde büyümesini umuyorum
Bugünkü LLVM'de CPU üreticilerine göre çatallanmış sürümler çoğalıyor ve her birinde CPU'ya özel iyileştirmeler kapalı paketlere bağlanmış durumda
Başka bir dil frontend'i kullandığınızda ya da derleyici hatası çıktığında işler çok zorlaşıyor
Diller diğer backend'lere serbestçe geçebiliyorsa buna nasıl tuzak denebilir diye soruluyor
Derleme hızı geliştirmeyi engelliyorsa neden bir interpreter yapılmıyor diye soruluyor
Çalışma hızı ile derleme hızı özünde bağımsız şeyler
Interpreter kullanırsanız kod enstrümantasyonu ya da çalışma zamanı kontrolü gibi ek geliştirme araçlarını yapmak da kolaylaşır
Yalnızca optimize edilmiş RELEASE binary'sini debug etmeniz gereken çok az sayıda durum var, çoğu durumda interpreter ya da DEBUG build yeterli
Duyduğuma göre Rust güvenlik, performans, kullanılabilirlik sırasını; Zig ise performans, kullanılabilirlik, güvenlik sırasını önceliklendiriyor
Bu açıdan bakınca build hızı iyileştirmeleri ikna edici ama interpreter, kullanılabilirliğin öncelikli olduğu durumda daha uygun bir alternatif
Julia'nın yaklaşımını seviyorum
Tam etkileşimli bir ortamda interpreter aslında kodu derleyip hemen çalıştırıyor
SBCL gibi Common Lisp ortamları da benzer şekilde çalışıyor
Çalışma hızı ve derleme hızı uç noktada bakıldığında bağımsız
Arada bir "uzlaşma alanı" var ve yürütülebilir dosyanın performansını düşürmeden derleyiciyi daha hızlı yapmak mümkün olabiliyor
Oyun alanının özel bir istisna olmadığı söyleniyor
Şimdiye kadar gördüğüm en iyi derleyici hızı TCC'de (Fabrice Bellard'ın işi)
Çoklu iş parçacığı ya da karmaşık optimizasyonlar olmadan bile ezici derecede hızlı
Release için Clang kullanıyorum ama TCC'nin kod üretim performansı da kötü değil
Delphi'nin çok daha ifade gücü yüksek ve daha güvenli olmasına rağmen yine de çok hızlı derleme sunduğunu düşünüyorum
Go derleyicisi de epey hızlı
DMD'nin hem C hem D derleyebilmesiyle "gold standard" olduğunu düşünürdüm
Keşke TCC C23 desteği verse
Tek bir şeyin "gerçek gold standard" olduğunu söylemek doğru değil
vlang de yeniden derlemeyi birkaç saniyede bitirecek kadar hızlı ve Go derleyicisi de son derece hızlı
Ayrıca build caching gibi tekniklerle yeniden derlemeyi tamamen önlemek de mümkün; bu tek bir aracın ayrıcalığı değil
zig ile uygulama build ederken incremental build deneyiminden çok memnun kaldım
SQLite, luau gibi çeşitli kütüphaneler kullanan tek bir statik binary'yi neredeyse Go kadar hızlı build edebiliyor
Ama self-hosted derleyicide hâlâ epey hata var
Örneğin SQLite için llvm kullanmak gerekiyor; ilgili issue'a buradan bakılabilir
Zig'in Bazel, Buck2 gibi build sistemleriyle iyi entegre olup olamayacağını merak ediyorum
Zig'de build script'leri Turing-complete olduğu için bu tür sistemlerde caching ve build otomasyonu zor olmaz mı diye endişeliyim
Bu, Rust'ta build.rs gerektirmeden kullanılabilen kütüphanelerin daha çok tercih edilmesine benziyor
Zig kütüphanelerinde de custom build çok yaygın mı merak ediyorum
Zig'in build script'leri tamamen opsiyonel
build.zig olmadan da tekil kaynak dosyalarını doğrudan build edip çalıştırabilirsiniz
Zig, GCC ya da Clang kullanılan her türlü iş akışına entegre edilebilir
Bu arada Zig, C derleyicisinin yerine de geçebilir
İlgili yazı
Bazel ile Zig entegrasyonuna örnek olarak rules_zig tanıtılıyor
Gerçek proje ZML de bunu kullanıyor
ZML projesi
Zig'in derleme ve kod üretimi açısından TPDE ile karşılaştırıldığında nasıl olduğunu merak ediyorum
LLVM -O0'dan 10~20 kat daha hızlı deniyor ama yine de sınırları var gibi
Zig'in stratejisini cesur buluyorum
Ama hâlâ LLVM backend kullanmasının doğru tercih olup olmadığını merak ediyorum
LLVM derleme hızı ve platform desteğinde rekabetçi ama en iyi makine kodunu üretme konusunda rakipsiz
LLVM backend yalnızca Release build'lerde kullanılıyor ve debug build'lerde desteklenen platformlarda varsayılan olarak self-hosted yaklaşım tercih ediliyor
Debug build'ler gerçek test sürecinde defalarca yapıldığı için bu yaklaşım daha mantıklı
Derleyici performansına bu kadar takılmayı anlamıyorum
Sonuçta optimizasyon geçitleriyle (inlining, dead code elimination vb.) derleme süresi arasında bir trade-off var
Optimizasyonsuz derleyiciler yalnızca doğrusal biçimde hızlanabilir; bunun ötesindeki optimizasyonlar kaçınılmaz olarak daha fazla zaman alır
"Mükemmel assembly çıktısı" pratikte çok önemli bir mesele değil
Proebsting's Law'a göre derleyici teknolojisindeki ilerleme, makine performansındaki artıştan çok daha yavaş
Kolay ve hızlı optimizasyonlarla pratikte yeterince iyi sonuç almak genelde mümkün
LLVM mutlak optimizasyon sunmuyor ve derleme hızıyla karşılaştırıldığında da çabucak sınırlarına dayanıyor
JNI ile C kütüphanelerini saran bir Java kütüphanesi yaparken, platforma göre dynamic library build etmek çok zahmetli olduğu için zig ile çoklu platform build denemeyi düşünüyorum
Sadece basit bir shim ise modern Java'da Panama ve jextract kullanmak daha iyi olabilir
Zig; header'ları, libc kaynaklarını ve kendi LLVM'sini gömülü getiriyor, bu yüzden cross-compilation gerçekten çok kolay
Neredeyse hiçbir şeyle uğraşmanız gerekmiyor
Ghostty'nin şu anda neden self-hosted x86_64 backend ile build edilemediği soruluyor
Zig derleyicisi bir bug yüzünden crash oluyor
Hâlâ yeni bir teknoloji olduğu için karmaşık, ama yakında çözülecektir
Ghostty kullanıcılarının çoğu aarch64 platformunda