Zig: Derleme Sistemi Yeniden Çalışması

 (ziglang.org)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • zig build iç yapısı configurer ve maker süreçlerine ayrıldı ve build.zig tarafından oluşturulan derleme grafiği ikili bir yapılandırma dosyasına serileştiriliyor
  • Üst süreç yapılandırma dosyasını önbelleğe alıyor ve maker'ı Release modunda eşzamansız derliyor; maker ise her Zig sürümü için genel önbellekte yalnızca bir kez derleniyor
  • Kullanıcının build.zig dosyası değiştiğinde artık tüm derleme sistemi onunla birlikte derlenmediği için --watch, --fuzz, --webui gibi özellikleri eklemenin zaman maliyeti azalıyor
  • zig build --help ortalama çalışma süresi 150ms'den 14.3ms'ye düştü; CPU döngüleri, komut sayısı ve önbellek erişimleri de %94–96 aralığında azaldı
  • API'lerin çoğu uyumlu kalıyor ancak b.args'ın doğrudan gözlemlenmesi addPassthruArgs() ile değiştiriliyor ve Zig 0.17.0'ın birkaç hafta içinde çıkması planlanıyor

Derleme sistemi mimarisindeki değişiklik

  • Büyük dal birleştirildi ve zig build iç yapısı configurer süreci ile maker süreci olarak ayrıldı
  • Eski yapıda build.zig dosyası ile derleme sistemi uygulamasının tamamı tek ve büyük bir Debug modu süreci olarak derleniyordu; build.zig bellekte derleme grafiğini oluşturuyor, ardından “build runner” bunu çalıştırıyordu
  • Yeni yapıda build.zig, küçük bir Debug modu configurer süreci olarak derleniyor ve derleme grafiği ikili yapılandırma dosyasına serileştiriliyor
  • Üst zig build süreci yapılandırma dosyasını algılayıp sonraki çalıştırmalar için önbelleğe alıyor ve derleme grafiğini yürütmekten sorumlu maker'ı Release modunda eşzamansız derliyor
  • Yapılandırma dosyası ve maker derlemesi hazır olduğunda maker yapılandırma dosyasını alıp çalışıyor; maker ise genel önbellek sayesinde her zig version için yalnızca bir kez derleniyor

Hız iyileştirmelerinin etkisi

  • Temel hedef zig build hızını artırmak ve kullanıcının build.zig dosyası değiştiğinde artık tüm derleme sistemini onunla birlikte yeniden derlememek
  • --watch, --fuzz, --webui devreye girdikçe derleme sistemine yeni işlevler eklense bile zig build süresinin bununla birlikte artmamasını sağlamak daha da önemli hale geliyor
  • Hiçbir değişiklik olmadığına karar verilirse build.zig mantığı yeniden çalıştırılmadan önceki yapılandırma yeniden kullanılabiliyor
  • Örneğin zig build komut satırına -freference-trace eklense bile build.zig mantığı gereksiz yere yeniden çalıştırılmıyor
  • Gerçek derleme grafiğini çalıştıran süreç optimizasyonlar açık şekilde derlendiği için yürütme aşaması da hızlanıyor

Benchmark sonuçları

  • zig build --help ortalama çalışma süresi eski yapıda 150ms iken yeni yapıda 14.3ms oldu
  • Duvar saati süresi 150ms'den 14.3ms'ye %90.4 azaldı; CPU döngüleri 593M'den 24.1M'ye %95.9 azaldı
  • Komut sayısı 995M'den 43.7M'ye %95.6 azaldı ve önbellek erişimleri 25.8M'den 1.46M'ye %94.3 azaldı
  • Zirve RSS 84.8MB'den 78.5MB'ye %7.4 azaldı
  • En büyük fark, her zig build komutunda build.zig mantığını çalıştıran yaklaşımdan, önbelleğe alınmış serileştirilmiş yapılandırmayı yeniden kullanan yaklaşıma geçilmesinden kaynaklanıyor

Araçlar ve uyumluluğa etkisi

  • ZLS gibi üçüncü taraf araçlar, build runner'ı çatallayıp sürdürmek yerine serileştirilmiş yapılandırma dosyasını tüketen bir yaklaşımla avantaj sağlayabilir
  • İç mekanizmalar büyük ölçüde değişmiş olsa da API açısından çoğunlukla uyumluluk korunuyor
  • İstisnalar, birleştirilen PR'da listelenen değişikliklerle sınırlı

Başlıca kırıcı değişiklik

  • Birçok kullanıcının karşılaşma ihtimali en yüksek değişiklik, b.args'ı doğrudan gözlemleyen kalıbın kaldırılması
  • Eski kod:
if (b.args) |args| {
    run_cmd.addArgs(args);
}
  • Yeni kod:
run_cmd.addPassthruArgs();
  • Bu değişiklikle derleme betiği artık bu argümanları gözlemleyemiyor; yani bir işlev kaldırılmış oldu
  • Buna karşılık bu argümanlar değişse bile derleme betiğini kaynaktan yeniden derlemek gerekmiyor

Testler ve sürüm takvimi

  • Zig'in yönünü etkilemek isteyen kullanıcılar projelerini geliştirme sürümüne yükseltip yeni değişiklikleri deneyebilir ve geri bildirim verebilir
  • Zig 0.17.0'ın birkaç hafta içinde yayımlanması planlanıyor
  • Önceden test etmeye zaman olmadığı ve 0.17.0'da derleme bozulsa bile, düzeltmelerin 0.17.1 etiketine girmesi için yeterli fırsat olacağı belirtiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • Bazı kodlarımı Zig 0.16.0’a taşıdım ve sonuçtan oldukça memnun kaldım
    Etkilenen kısımlar oldukça fazlaydı, ama değişikliğin kendisi iyiydi ve dilin geleceğini daha parlak kılan bir yönde görünüyor
    Özellikle yeni giriş/çıkış mekanizması, tek iş parçacıklı, çok iş parçacıklı ve olay döngüsü tabanlı uygulamaların hepsinde temiz görünümlü ve verimli kod yazmayı mümkün kılıyor
    0.16.0’dan beri Zig’e bakmadıysanız mutlaka göz atmanızı öneririm. Bu sürüm notları inanılmaz uzundu
    https://ziglang.org/download/0.16.0/release-notes.html

    • Buna henüz “çok verimli” demek zor. Io hâlâ dinamik dispatch kullanıyor ve birden fazla dolaylı başvuru katmanı var
      Bildiğim kadarıyla öncekinden daha yavaş
      Sonraki sürümlerde, “dispatch hedefi derleme zamanında biliniyor ama hâlâ dinamik” sorununu çözüp verim kaybını azaltmalarını bekliyorum
    • Yeni giriş/çıkış mekanizmasının, özellikle de async/await’in nasıl çalıştığını anlamakta biraz zorlandım
      io.async olay döngüsü tabanlı bir IO uygulamasında çağrıldığında, içeride bir tür “task” başlattığını ve future’ın da onun handle’ı olduğunu varsayıyorum
      Anlamadığım kısım future.await(io) çağrıldığında ne olduğu. IO uygulaması mevcut fonksiyonu bir şekilde durdurup future çözüldüğünde devam mı ettiriyor? Eğer öyleyse, bu Zig’deki tüm fonksiyonların stackless coroutine olduğu anlamına mı geliyor?
    • Bir gün bu yeni özellikleri kullanabilirim ama kararlılık ve daha az test edilmiş hedefler yüzünden Zig derlemelerinde .use_llvm = true kullanıyorum

  • Zig’i birkaç aydır kullanınca bunun mükemmel bir araç dili olduğuna ikna oldum
    Fikirleri serbestçe ve kaba taslak denemek için eline alması çok iyi, tıkandığın noktalarda da dili yapanların önceden düşünmüş olduğu rahat çözümler var
    Buna rağmen sana dilin “doğru” kullanımını dayatmıyor
    Artık benim için varsayılan “garajda kurcalama” dili oldu

    • “Doğru” kullanım dayatmıyor demek biraz zor; kullanılmayan değişkenlere izin vermiyor ve çok satırlı yorum da yok
      Benim için bunlar epey büyük üretkenlik sorunları
    • Gerçekten o kadar iyi mi?
      Benim varsayılan “garajda kurcalama” dilim Python. Hafif sözdizimi, engel çıkarmayan kullanım hissi, zengin standart kütüphane; olmayan şeyler için de paket var
      Zig’in avantajı ne?
    • Benim asıl takıldığım nokta şu: deneysel işler için varsayılan dilim muhtemelen Mojo olacak
    • Kesinlikle harika bir deney dili ama Zig ekibi ve topluluğunun dili “doğru” kullanma biçimi konusunda çok güçlü tercihleri var

  • Andrew Kelley ile yapılan röportaj videosunu izledim ve Zig öğrenmek istedim: https://www.youtube.com/watch?v=iqddnwKF8HQ

    • Andrew’a gerçekten saygı duyuyorum ve Zig’i de keyifle kullanıyorum ama o röportaj berbattı
      Andrew’un yanıtları iyiydi ama genel hava fazla yağcılık kokuyordu

  • Zig’i denemek istedim ama dil hâlâ fazla hızlı değişiyor
    Her sürümde API kırılıyor, bu yüzden dili öğrenmeyi, build sistemini debug etmeyi ve gerçekten yapmak istediğim şeyi aynı anda takip etmek zor oldu
    JetBrains röportajını gördükten sonra tekrar denemek istiyorum ama muhtemelen 1.0 çıkana kadar bekleyeceğim

  • Uzun zamandır ikili programlama diye adlandırdığım bir fikir üzerine düşünüyorum
    Yığını tam olarak iki dilden, yani bir yüksek seviyeli ve bir düşük seviyeli dilden oluşturma yaklaşımı
    Mümkün olduğunca çok şeyi yüksek seviyeli dilde yazıp, yalnızca gerektiğinde düşük seviyeli dile iniyorsun
    Sorun şu ki, düşük seviyeli dili zaten çok iyi bilmiyorsan, o seviyede iş yapmadan önce yeniden alışman gerekebiliyor
    Bu yüzden C++ ya da Rust, C’den daha zor hale geliyor ve benim için varsayılan seçenek C oluyor. Ama C’nin de iyi bilinen sorunları var
    Zig, uzun aralardan sonra bile yeniden eline almayı kolaylaştıracak kadar basit olup, aynı zamanda programlamayı kolaylaştıran modern araçlar sunduğu için bu tatlı noktayı iyi doldurabilir gibi görünüyor

    • Bu fikir ilginç ama ben tersini düşünüyorum
      Mümkün olduğunca çok şeyi düşük seviyeli dilde yapıp, ancak sağladığı kolaylık maliyetine değdiğinde yüksek seviyeli dile çıkmak gerektiğini düşünüyorum
      Roc bunu mümkün kılıyor. Her programın düşük seviyeli dilde yazılmış bir platformu var ve Roc programı da bu platformun sunduğu API’yi kullanıyor
      https://www.roc-lang.org/
      Elbette yüksek ve düşük seviye arasındaki dengeyi nasıl kuracağı herkesin kendi seçimi
    • Bildiğim kadarıyla SpaCy de bu şekilde geliştiriliyor
      Modeller Cython ile uygulanıyor, kullanıcıya dönük API ise Python olarak sunuluyor
    • C# bu hedefe epey yakın
    • Ya Rust gibi hem yüksek seviyeli hem düşük seviyeli programlamayı iyi yapan tek bir dil kullanın
      Şu anda her şey için Rust kullanıyorum ve özellikle OCaml benzeri tür sistemi sayesinde, onunla yapamadığım bir şeyle henüz karşılaşmadım
    • Bu tür bir kombinasyonda eskiden yaygın olan ikili C ve Lua idi
      Lua gömülü bir dil olarak tasarlandığı için birlikte çalışabilirlik açısından iyi, aynı zamanda yüksek seviyeli olduğu için kullanımı da kolay
      Factorio’nun betik dili olarak Lua kullanmasının bir nedeni var

  • Zig geliştirmede hoşuma giden şey, dil özellikleri eklemekten çok araçlara ve geliştirici geri bildirim döngüsüne şaşırtıcı ölçüde emek harcamaları
    Yeni bir dil bir süre bir özelliği eksik olsa da hayatta kalabilir
    Ama derleme, linkleme ve bağımlılık güncelleme her seferinde yavaş hissettiriyorsa ayakta kalmak çok daha zor
    Geliştirme döngüsünü saniyeler yerine milisaniyeler düzeyine indirme odakları, uzun vadede iyi bir tercih gibi görünüyor

  • “Birkaç hafta içinde 0.17.0 yayımlamayı planlıyoruz” demeleri şaşırtıcı
    0.16’nın çıkması bir yıldan fazla sürmedi mi?
    0.17’nin bu kadar hızlı gelmesini beklemiyordum; bunu bugün öğrenmek beni çok sevindirdi

  • Kulağa iyi haber gibi geliyor. Zig'in derleme süresi zaten harika, bu değişiklikle daha da iyi olacak gibi.

    • Benim deneyimime göre bu ifade şimdilik çoğunlukla hedefe daha yakın demek.
      Kesinlikle önemli bir hedef ve buna nasıl ulaşılacağına dair kilometre taşları da net, ama pratikte boş bir projenin ilk derlemesi ya da direnv allow sonrası ZLS yeniden derlenirken yaşanan o can sıkıcı bekleme süresine “harika” demek zor.
    • İçinde sahte bir test bulunan tek bir dosya oluşturup zig test file.zig -OReleaseSafe çalıştırınca bile benim bilgisayarımda birkaç saniye sürüyor.
      Dosyayı her değiştirdiğimde yine aynı süre gerekiyor. 0.16 veya master kullanıyorum, yani toolchain eski de değil, üstelik Linux'tayım.
      Zig dilinin kendisini kullanmak gerçekten çok keyifli ama derleyici ve standart kütüphane bana yeterince muhafazakâr geliştirilmiyor gibi geliyor.
      hello world ile başlarken bu sorunlarla karşılaşmayabilirsiniz ama fuzz test ya da benchmark yaparken optimize edilmiş binary çalıştırmak istiyorsunuz.
      O zaman da görece küçük bir kod miktarını derlemek bile fazla sinir bozucu oluyor.
      Karşılaştırma yapmak gerekirse Zig'in dil olarak Rust/C++/C'den çok daha iyi olduğunu düşünüyorum, ama Rust/C++/C tarafında bu tür sorunlar pratikte neredeyse hiç yaşanmıyor. C/C++ için clang/gcc/ninja vb. kullandığınızı varsayıyorum.
      Aynı bilgisayarda Ninja/Python/clang ile yaklaşık 10 bin satırlık bir C++ projesini kurup derleyip (-O2 veya -O3) test etmeyi 200ms içinde yapabiliyorum.
    • Neyse ki 90'lar tarzı derleme hızı yavaş yavaş geri dönüyor.

  • Zig'in Linux kütüphane stub'larını dışa aktarmak için resmî bir mekanizmaya sahip olması harika olurdu.
    Zig'in çapraz derleme ve istenen glibc sürümünü hedefleme yeteneği tam anlamıyla sihir gibi.
    Bu sihri ayrı bir C++ build system içinde kullanıyorum ama Zig'den o kütüphane stub'larını almak için dolambaçlı yollara başvurmak gerekiyor.
    Bunların resmî çıktı olarak sunulması güzel olurdu.

  • İnsan neden Node.js ve TypeScript yerine bunu kullanmak istesin ki?

    • Bu düşünce tarzını kıskanıyorum. Ben de böyle olsaydım muhtemelen şimdiye kadar yayımladığım çok daha fazla uygulama olurdu.
    • Zig ile yazılmış Ghostty'yi kısa süre deneyip JavaScript ile yazılmış Hyper gibi terminallerle karşılaştırmanızı öneririm.
    • Çünkü ikisi tamamen farklı alanlara hitap etmiyor mu?
    • Yapacağınız iş Node ve TypeScript'e uygunsa, öğrenme ya da merak dışında Zig kullanmak için bir sebep görmüyorum.
      Performansın son damlasına kadar çıkmak ya da bellek yerleşimi ve kontrolüne ihtiyaç duymuyorsanız Zig kullanmanın eksileri daha fazla.
      CRUD veya “enterprise” işleri, web siteleri gibi alanlarda Zig'in avantajı neredeyse hiç yok.
    • Gömülü sistemlerde bellek kısıtlı olduğu için Node çalıştırılamaz.
      Derlenmiş bir Zig programı bağımlılık olmadan sadece birkaç KB olabilir.
      Düşük seviyeli bir dilde yazılmış dizi erişimi SIMD ve paralelleştirme ile optimize edilebilir; bu da aynı işi JavaScript ile yapmaktan birkaç büyüklük mertebesi daha hızlı olabilir.
      Metin işleme, görüntü düzenleme, video işleme, hashing gibi alanlarda fark büyük.
      JavaScript kullanmamak için pratikte sonsuz sayıda sebep var.