Hata ayıklama modunda self-hosted x86 backend varsayılan oldu

 (ziglang.org)
1 puan yazan GN⁺ 2025-06-09 | 1 yorum | WhatsApp'ta paylaş
  • Zig, x86_64 hedeflerinde LLVM’in bitcode’u nesne dosyasına indirdiği varsayılan yolu self-hosted x86 backend ile değiştirerek hata ayıklama derlemelerinde derleme hızını ve bellek kullanımını büyük ölçüde azalttı
  • Self-hosted x86 backend, 1987 behavior test’i geçti; bu sayı LLVM backend’inin geçtiği 1980 testten fazla. Toplam 2084 testin içindeki bazı ek testler ise yalnızca self-hosted x86 testlerinde çalıştırılıyor
  • hello.zig benchmark’ında LLVM yolundaki ortalama 918ms, varsayılan self-hosted backend’de 275ms’ye düştü; böylece wall time %70,1 azaldı ve peak RSS de 214MB’den 137MB’ye indi
  • Zig compiler’ın kendisi gibi büyük projelerde de derleme süresi 75 saniyeden 20 saniyeye düştü; ancak Windows tarafında COFF linker için daha fazla çalışma gerektiğinden varsayılan değişikliği henüz burada uygulanmadı
  • Kalan işler arasında kod üretiminin tamamen paralelleştirilmesi, linker iyileştirmeleri, incremental compilation’ın kararlı hale getirilmesi, x86 kod kalitesinin artırılması ve aarch64 backend’inin genişletilmesi yer alıyor

x86_64 için varsayılan backend değişimi

  • x86_64 hedefleri için derleme yapan Zig artık varsayılan olarak self-hosted x86 backend kullanıyor
  • Önceki varsayılan yol, LLVM’in bitcode dosyasını nesne dosyasına indirmesiydi
  • Windows’ta varsayılan henüz değişmedi
    • Bunun nedeni COFF linker tarafında daha fazla çalışma gerekmesi

Behavior test geçiş durumu

  • Self-hosted x86 backend 1987 behavior test’i geçiyor
  • LLVM backend 1980 behavior test’i geçiyor
  • Toplam behavior test sayısı 2084, ancak ek testler çoğunlukla LLVM’in kendi x86 backend testleriyle örtüşüyor
    • Bu ek testler yalnızca self-hosted x86 testleri sırasında çalıştırılıyor
  • Geçilen test sayısına göre Zig’in x86 backend’i, Zig dil uygulamasında LLVM backend’inden daha ileride bulunuyor

Neden LLVM yolu ile rekabet ediyor?

  • Zig’in kod üretiminde LLVM ile rekabet etmesinin en büyük nedeni, derleme hızı farkını çok belirgin hale getirebilmesi
  • İlgili arka plan, Ziggit açıklamasında özetleniyor

hello.zig benchmark’ı

  • zig build-exe hello.zig -fllvm sonucu:
    • Ortalama wall time: 918ms
    • Peak RSS: 214MB
    • CPU cycles: 4.53G
    • instructions: 8.50G
  • zig build-exe hello.zig varsayılan yol sonucu:
    • Ortalama wall time: 275ms
    • Peak RSS: 137MB
    • CPU cycles: 1.57G
    • instructions: 3.21G
  • Varsayılan self-hosted backend, LLVM yoluna kıyasla çeşitli metriklerde düşüş sağlıyor
    • wall time %70,1 azalma
    • peak RSS %36,2 azalma
    • CPU cycles %65,2 azalma
    • instructions %62,2 azalma
    • cache misses %86,1 azalma
    • branch misses %78,3 azalma

Büyük projelerdeki etkisi

  • Zig compiler’ın kendisi gibi daha büyük projelerde derleme süresi 75 saniyeden 20 saniyeye düşüyor
  • Self-hosted x86 backend, yalnızca küçük örneklerde değil büyük kod tabanlarında da derleme süresini ciddi biçimde azaltabiliyor

Sonraki çalışmalar

  • Zig, kod üretiminin tamamen paralelleştirilmesi için çalışmalara zaten başladı
  • Linker iyileştirmeleri ve hata düzeltmeleri ilerledikçe incremental compilation bu backend ile daha kararlı ve sağlam hale getirilebilecek
  • Üretilen x86 kodunun kalitesinde hâlâ iyileştirme alanı bulunuyor
  • Sıradaki hedef aarch64; yeni Legalize pass sayesinde çalışmaların hızlanması bekleniyor
  • En güncel master branch derlemeleri Zig indirme sayfasından indirip doğrudan denenebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-09
Hacker News yorumları

  • Bildiğim kadarıyla Zig’de daha iyi bir geliştirme deneyimi için süren çok iş var. Neredeyse her gün bir şeyler üzerinde çalışılıyor; az önce de https://github.com/ziglang/zig/pull/24124 gibi bir şey geldi
    Eskiden hot code replacement’ın da planlandığını biliyorum; mevcut geliştirme hızıyla x86_64 üzerinde bir yıl içinde çalışsa şaşırmam
    Şu anda kişisel olarak en büyük sancım comptime hızı. Derleyicinin burada yapacak çok işi var ve derleme zamanında brainF** DSL çalıştırmak epey yavaş. Kendim denedim; komik bir deneydi
    Zig’in kullanıma aldığı yeni backend’ler genel olarak çok heyecan verici. Zig için URCL(https://github.com/ModPunchtree/URCL) backend’ini kendim yapmayı denemek istiyorum

    • comptime performansını iyileştirmek için ne yapılması gerektiğini biliyoruz ve uzun zaman önce bunun için bir branch üzerinde çalışmaya da başlamıştık. Ancak semantik analiz kodunun büyük kısmını yeniden işlemek gerekiyor; yani kesinlikle yapılabilir, yapılmalı ve yapılacak bir iş, ama diğer önceliklerle rekabet ediyor
    • Hot code replacement oyun geliştirme için muazzam olur. Zig’in bunu fiilen tek bir derleyici bayrağıyla yerleşik olarak destekleyecek olması fikri harika. Aynısını clang ile denemelerini isterim
    • comptime’ın yavaş olmasının gerçekten sorun olup olmadığını merak ediyorum. Bir JSON-RPC kütüphanesi yapıyorum ve JSON isteklerini rastgele fonksiyonlara dispatch etmek için comptime’a ciddi biçimde dayanıyorum
      Katı statik tipler yüzünden çalışma zamanında rastgele parametrelere sahip fonksiyonlara dinamik dispatch yapmanın bir yolu yok; bulduğum tek yöntem derleme zamanında comptime ile fonksiyon tipi eşlemesini çıkarmaktı
      Her rastgele fonksiyon için comptime’lanmış kod kopyası arttığından kod boyutu muhtemelen büyüyecek
    • Özel backend yapmanın kolay olup olmadığını merak ediyorum. Henüz bakmadım ama denemek istiyorum
      Somut olarak AIR’i alıp bellek güvenliği raporu üreten bir backend yapılabilir gibi geliyor. Tanımsız değer kullanımı, stack pointer’ın dışarı kaçması, serbest bırakıldıktan sonra kullanım, çift serbest bırakma, alias xor mut gibi şeyleri tespit etmek gibi
    • URCL yüzünden tavşan deliğine düşüyorum. Henüz derinlemesine bakmadım ama en komik zaman çizgisi, Minecraft için yapılmış bir ara temsilin birçok dil için pratik bir derleme hedefi hâline gelmesi olurdu

  • Zaten muazzam bir başarı, ama geliştirme günlüğünde yazdığı gibi önümüzde daha da fazlası var. Derleme sırasında binary’de yalnızca gerekli kısımları değiştiren bir derleyici fikri hem taze hem de tamamen radikal; artık Zig projesinin erişebileceği bir noktaya gelmiş gibi görünüyor
    Devamını merakla bekliyorum

  • “Zig derleyicisi gibi büyük projeler 75 saniyeden 20 saniyeye düşüyor. Bu daha sadece başlangıç” kısmı heyecan verici. Bu kişinin bununla neler yapabileceğini merak ediyorum; gerçekten çok zeki görünüyor
    Paket yönetimi ne durumda merak ediyorum. QuickJS + SDL3 uygulaması yapmayı denemiştim ama C++ tarafındaki karmaşa yüzünden Rust’a geçtim; orada doğrudan sorunsuz çalıştı. Zig’de de deneyebilmek isterim

    • Zig’in paket yönetimi Rust’a göre daha manuel. CLI ile paket URL’sini alıp ardından build script’te modülü içe aktarma şeklinde çalışıyor
      Avantajları da var; rastgele arşivlere bağımlı olabiliyorsunuz ve C kütüphanelerini saran birçok Zig paketi, değiştirilmemiş tarball sürümlerine dayanan build script’lere daha çok benziyor. Elbette yeni başlayanlar için biraz daha zor
      SDL3 için native bir Zig wrapper var: https://github.com/Gota7/zig-sdl3
      C kütüphanesi/API’sini daha temel biçimde yeniden paketleyen bir seçenek de var: https://github.com/castholm/SDL
      QuickJS için tek seçenek C API: https://github.com/allyourcodebase/quickjs-ng
      Zig bu şekilde C paketlerini doğrudan kullanmayı çok kolaylaştırıyor, ancak Zig’in tipleri çok daha katı olduğu için API ile etkileşimde çok sayıda cast yapmanız gerekiyor
    • dmd D derleyicisi kendisini debug build olarak derleyebiliyor
      real 0m18.444s, user 0m17.408s, sys 0m1.688s
      Çok eski bir işlemcide bile bu seviyede; o kadar hızlı çalışıyor ki yükseltme yapma gereği duymadım
      Özellikleri AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2 çekirdek, 2.3GHz, 512KB cache gibi
    • Bunu yapmaya yönelik bir rehber var mı merak ediyorum. Zig’i derlediğimde birçok aşamadan geçtiği için uzun sürmüştü ve wasm’dan bootstrap edilen tüm süreç de dahildi
    • Zig’in kendisini 75 saniyede derleyebilmesi şaşırtıcı. LLVM kullanıyor olsa bile

  • D ve Nature için de söylediğim gibi, kendi backend’ine sahip tüm diller açısından LLVM’e bağımlı olmamaya çalışan projeleri destekleme yükümlülüğümüz var
    LLVM yüzünden derleyici Ar-Ge’si durakladı; çok fazla dil LLVM’e bağımlı olmayı seçti ve çok fazla kişi hızlı yineleme sürelerini değerli görmemeye ya da daha iyisini beklememeye başladı gibi
    Artımlı derleme ve binary patching ile hızlı yineleme, ayrıca iyi debugging yeni dillerden beklenti olmalı; niş özellik ya da fazla zor bir iş muamelesi görmemeli

    • Öte yandan LLVM, bireylerin yaptığı dillerin bile hemen rekabetçi performans ve geniş platform desteği kazanmasını sağlayarak patlama yaratmasına imkân verdi. Zig de bunlardan biri
      Gerçek zamanlı rendering sektörünün tamamı fiilen LLVM ya da LLVM fork’ları üzerine kurulu; Microsoft da shader derleyicisini LLVM’e çevirdi ve kodu ancak şimdi upstream etmeye başladı
      Çoğu oyun konsolunun derleyici altyapısı da Clang tabanlı. Xbox bugüne kadar MSVC’de ısrar ediyor ama bu istisnaya yakın
      Genel olarak LLVM, özellikle yeni şeyleri bootstrap etmekte muazzam bir başarı elde etti
    • Doğru. Go’da olumlu gördüğüm az sayıdaki şeyden biri bootstrap edilmiş olması ve LLVM’e bağımlı olmaması

  • Talepkâr ya da minnet bilmez biri gibi görünmek istemem. Sonuçta Zig ücretsiz yapılan bir iş. Ama en çok merak ettiğim şey gerçekçi 1.0 takvimi
    Zig, düşük seviyeli bir dilde istediğim şeye neredeyse tam olarak uyuyor ve kararlı hâle gelmesini bekliyorum
    Elbette Zig’in minimal tasarım felsefesini gerçekten takdir ediyorum

    • TigerBeetle gibi ciddi projeler sürümü sabitliyor; muhtemelen en güncel release’i kullanıyorlardır. nightly’yi daha çok deneysel görüyorum

  • zig init ile oluşturulan hello world programı derlenince 9,3 MB oluyor. -Doptimize=ReleaseSmall ile elde edilen 7,6 KB ile karşılaştırınca 1000 kattan fazla büyük; bu inanılmaz

    • Doğru bir gözlem. Bir başka gözlem de bunun %82’sinin debug bilgisi olduğu
      -OReleaseSmall -fno-strip 580 KB’lık bir çalıştırılabilir dosya oluşturuyor, -ODebug -fstrip ise 1,4 MB’lık bir çalıştırılabilir dosya oluşturuyor
      Zig’in x86 backend’i, Zig’i anlayan bir lldb fork’u ile birlikte çok daha iyi bir debug deneyimi sunuyor: https://github.com/ziglang/zig/wiki/LLDB-for-Zig
      Şu anda comptime mantığını adım adım çalıştırmanın mümkün olup olmadığını hatırlamıyorum. Yakın zamanda tartıştığımız bir konuydu

  • Julia’nın ciddi performans kazanımları elde etmesi için Zig’e geçmeyi düşünmesi gerekebilir gibi. Her LLVM release’inde performans düşüşü olacak mı diye kaygılanan Julia yazarlarını hatırlıyorum

    • Julia aslında LLVM’e güçlü biçimde bağlı. Ekosistemin büyük bir bölümü intrinsic’ler, otomatik türev alma (Enzyme) ve GPU derlemesi nedeniyle LLVM’in varlığına dayanıyor. Base ve Core’dan söz etmiyorum bile
      Derleyici oldukça yeniden hedeflenebilir ve bu da aktif olarak üzerinde çalışılan bir alan. Bu yüzden gelecekte dilin bazı parçaları için alternatif derleyici olarak Zig’i hayal etmek belki mümkün olabilir
    • LLVM, Julia’nın genel API’sinin bir parçası sayılmıyor mu? Gerçekten de IR’yi gösteren @code_llvm gibi makrolar var
    • Derleme süresini azaltmanın bir yolu olabilir, ama Julia tarafında hâlâ yapılacak çok iş olduğunu düşünüyorum
      Daha ince taneli derleme önbelleği, geçersizleştirmeyi önleyen daha iyi araçlar, world splitting optimizasyonunun kaldırılması, derleyicide çok iş parçacığından daha fazla yararlanma, somut imzaların otomatik ön derlemesi, kod derlendiğinde hot-swap yapan daha tembel kod üretimi gibi şeyler
    • Her yeni derleyici backend’i çıktığında böyle şeyler söyleniyor. Oldukça şüpheciyim ama biri bunu proje olarak üstlenirse neler olacağını görmek ilginç olur

  • Tam bir acemi olarak Zig’in diğer dillerden daha iyi yanının ne olduğunu merak ediyorum. Daha modern bir C diye anlıyorum; peki bu modern kısım ne?

    • Aklıma gelenlerden birkaçını yazayım: Birden çok ayrı ve anlaşılması zor araç ve dil kullanmayan entegre bir build sistemi var
      C’nin dizilerinin aksine Zig’de uzunluğunu bilen slice’lar var; bu, buffer overflow açısından daha iyi. Açık seçim tipleri mutlaka kontrol edilmeli ve null pointer’lara izin verilmiyor. C koduyla entegrasyonda izin verilen durumlarda bile tip bunu açıkça ortaya koyuyor
      enum’lar, tagged union’lar ve switch ifadelerinde zorunlu tam kapsama kontrolü de var
      Hata işleme açık; fonksiyonlar çağıranın bir şekilde ele alması gereken hatalar (enum değerleri) döndürüyor. C’de bir fonksiyon hatayı temsil eden bir integer döndürse bile bunu tamamen görmezden gelebilirsiniz
      Ancak hatayla birlikte veri döndürmenin standart bir yolu dilin içine yerleşik değil. Parametre olarak hata struct’ı geçirme paterni sonradan eklenmiş gibi duruyor; bunun için özel sözdizimi olması gerektiğini düşünüyorum
      Fonksiyon dönüşü veya hata oluşması sonrasında temizlik için defer, errdefer blokları var; makrolar yerine comptime kod üretimi ve @typeInfo gibi tip reflection’ı kullanılabiliyor
      Kütüphanelere allocator geçirerek, çağıran taraf genellikle belleğin nerede ve nasıl ayrılacağına karar veriyor; sadece GeneralPurposeAllocator kullanmak bile bellek sızıntılarını bulmayı kolaylaştırıyor
      Programlamaya başladıktan sonra sürekli yüksek seviyeli diller kullandım ve C ile çevresindeki ekosistemin anlaşılması zor, sezgilere aykırı yönlerinden hoşlanmadım; Zig sayesinde ilk kez sistem programlamadan keyif almaya başladım

  • Bu sadece backend’in değiştirilmesi mi? Tüm analiz ve tip pass’leri hâlâ duruyor mu, yoksa doğrulama da azaltılıyor mu merak ediyorum
    Hızlı derleme döngüleri üretkenliğe yardımcı olur, ama bence ancak hızlı testleri de içeriyorsa
    Öyleyse debug için Zig’i doğrudan yorumlayarak çalıştırmak daha kolay olmaz mı? Böylece her hedef için işi tekrarlama sorunu da çözülmüş olur gibi

    • Debug modunun özü debug edilebilirlik; yorumlayarak çalışan Zig’i gdb ya da lldb gibi standart debugger’lara bağlamak hiç de önemsiz olmayacak gibi. Çünkü bu araçlar DWARF debug bilgisine sahip çalıştırılabilir dosyalar bekler
      Ek olarak, özellikle oyun geliştirme gibi alanlarda debug modu performansı da gerçekten çok önemli
    • Değiştirilen yalnızca backend. Testler de hızlanacaktır
      Bir interpreter eklemeye pratikte gerek yok. Custom backend olması, şu an debug için kullanılsa da çok daha uzak gelecekte hız açısından LLVM ile rekabet edebileceği anlamına geliyor
      Interpreter ekleseniz bile zaten custom backend yazmanız gerekeceği için faydası az
      Sorun, LLVM’in hem debug hem release’te yavaş olması

  • Bu, Zig’e async/await’i geri getirmek için önkoşullardan biri değil mi?
    https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-o...

    • O kısmı tamamen toparladık ve önümüzdeki 2-3 ay içinde ilginç bir güncelleme paylaşabileceğimizi düşünüyorum. I/O’yu en temelden yeniden kuruyoruz; işin çoğu standart kütüphane çalışması
    • Bağlantıyı okuyunca async geri dönmeyecekmiş gibi, ya da en azından 2028’e kadar dönmeyecekmiş gibi görünüyor