Zig – io_uring ve Grand Central Dispatch için std.Io uygulamaları eklendi

 (ziglang.org)
2 puan yazan GN⁺ 2026-02-15 | 1 yorum | WhatsApp'ta paylaş
  • Zig standart kütüphanesinin std.Io.Evented modülüne io_uring ve Grand Central Dispatch (GCD) tabanlı uygulamalar yeni entegre edildi
  • Her iki uygulama da kullanıcı alanı yığın geçişi (fibers, stackful coroutines, green threads) yöntemiyle çalışıyor
  • Şu anda deneysel aşamada ve hata işleme iyileştirmesi, logların kaldırılması, performans düşüşü nedenlerinin analizi ve testlerin güçlendirilmesi gibi ek çalışmalar gerekiyor
  • Aynı uygulama kodunda yalnızca I/O backend'ini değiştirerek io_uring veya GCD arasında kolayca geçiş yapmak mümkün
  • İki uygulama da Zig derleyicisinde çalışıyor ve gelecekte kararlı hale gelirse platforma özgü asenkron I/O için birleşik bir temel haline gelebilir

io_uring ve GCD tabanlı std.Io.Evented uygulaması

  • Zig 0.16.0 sürüm döngüsünün sonunda std.Io.Evented en güncel API değişikliklerini yansıtacak şekilde güncellendi

    • Yeni eklenen uygulamalar io_uring (Linux) ve Grand Central Dispatch (GCD) (macOS)
    • Her iki uygulama da kullanıcı alanı yığın geçişi (fibers, stackful coroutines, green threads) tekniğini kullanıyor

  • Her iki uygulama da şu anda deneysel durumda ve kararlı kullanım için geriye çeşitli iyileştirme başlıkları kalıyor

    • Hata işleme iyileştirmesi gerekli
    • Logların kaldırılması ve performans düşüşü nedenlerinin teşhis edilmesi gerekli (IoMode.evented kullanıldığında derleyici performansında düşüş görülüyor)
    • Bazı henüz uygulanmamış işlevler var ve test kapsamının genişletilmesi gerekiyor
    • İşlev bazında azami yığın boyutunu doğrulamak için yerleşik bir işlev eklenmesi gerekiyor (overcommit devre dışıyken pratik kullanım sağlamak amacıyla)

I/O uygulamasını değiştirme örneği

  • Aynı uygulama kodunda yalnızca I/O backend'i değiştirilerek çalıştırmak mümkün

    • Örnek kodda std.Io.Threaded yerine std.Io.Evented kullanılırsa io_uring tabanlı olarak çalışıyor
    • app işlevi aynı kalıyor ve çıktı sonucu da (Hello, World!) aynı oluyor

  • strace sonuçlarının karşılaştırılmasıyla iki çalışma biçimi arasındaki fark görülebiliyor

    • hello_threaded normal thread tabanlı I/O çağrılarını kullanıyor
    • hello_evented ise io_uring sistem çağrılarını (io_uring_setup, io_uring_enter vb.) kullanıyor

Zig derleyicisinde kullanım ve mevcut durum

  • Zig derleyicisinin kendisi de std.Io.Evented kullanarak düzgün şekilde çalışıyor

    • Hem io_uring hem de GCD üzerinde derleyici çalıştırılabiliyor
    • Ancak performans düşüşünün nedeni henüz belirlenmiş değil, bu yüzden ek analiz gerekiyor

  • Bu değişiklikle Zig kodu I/O uygulamasını kolayca değiştirebilen bir yapıya daha da yaklaşıyor

    • Platforma özgü asenkron I/O modellerini birleşik biçimde ele alabilecek bir temel hazırlanmış oluyor

Gelecekteki çalışmalar

  • Kararlı kullanım için performans iyileştirmeleri ve daha güçlü testler gerekiyor
  • Yığın boyutu yönetimi özelliği eklenirse, overcommit'in devre dışı olduğu ortamlarda da pratik kullanım mümkün olabilir
  • Tamamlandığında Zig'in asenkron I/O soyutlama katmanı daha da güçlenebilir

Sonuç

  • Bu güncelleme, Zig'in standart I/O sisteminin genişletilmesi açısından önemli bir ilerleme
  • io_uring ve GCD'nin entegre edilmesiyle platformlar arası asenkron işleme tutarlılığı için temel hazırlanıyor
  • Gelecekte kararlılık çalışmaları tamamlandığında, Zig'in yüksek performanslı ve esnek I/O modeli uygulama potansiyeli daha da artacak

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-15
Hacker News yorumları

  • Ben bir Zig hayranı değilim ama küçük bir ekibin istikrarlı şekilde ilerlemesini görmek güzel
    Tamamlanmış olmaktan çok deney ve kademeli iyileştirmeye önem veren yaklaşımları etkileyici
    1.0’ı aceleyle çıkarmak yerine uzun vadeli hedeflere doğru ilerlemek daha önemli diye düşünüyorum
    Tek bir kişi etrafında şekillenen bir proje için şaşırtıcı bir başarı ve emek veren insanların hak ettiği takdiri görmesi gerek

    • Ne zaman yeni bir dil öğrensem TCP/UDP çok oyunculu sunucusu olan bir oyun motoru yapmayı denerim; son zamanlarda bunu Zig ile denedim
      Şimdiye kadarki deneyimlerim içinde en eğlenceli ve en üretken olanıydı
      Rust’ın katı bellek yönetimindense Zig’in sadeliği bana çok daha uygun geliyor
      Hayat kısa; ben sadece hızlı ve iyi düzenlenmiş yazılım yapmak istiyorum

  • Zig hakkında her yazıda çok eleştiri oluyor ama insanların neden bu kadar takıldığını anlamıyorum
    Andrew ve ekibinin inandıkları şeyi gerçeğe dönüştürmeye çalışan mühendislik ruhu bana daha çok ilham veriyor
    Zig’in ana akım olup olmayacağını dert etmeye gerek yok; bir sorunu çözmeye yardım ediyorsa bu yeterli
    Dillere kimlikmiş gibi yaklaşmaya gerek yok

    • Bu durumu ortadan kaldırmak için programcıların aldığı ekonomik teşvikleri değiştirmek gerekir
      Diller ve kütüphaneler sonuçta “satılabilir beceriler” olduğu için insanlar kullandıkları araçların piyasadaki değerini düşünür
      Üstelik karar vericilerin mühendisleri kolayca değiştirilebilir varlıklar gibi görme eğilimi de sorun
    • Bu tür dil tartışmaları sadece Zig’e özgü değil
      Lisp, Ruby, Rust gibi dillerde de tekrar tekrar görüldü ve kimlik kavgası sektörün kronik sorunlarından biri
    • Yeni bir dil yığını, Linux dağıtımlarında bakım yükünü artırır
      Güvenlik ve mimari desteği gibi uzun vadeli bakım gerekirken geliştiriciler bunun maliyetini göz ardı ediyor
      Zig henüz kararlı olmadığı için paketler yalnızca belirli sürümlerde derleniyor
      Başka dillerdeki iyileştirmelerle çözülebilecek sorunları neden ille de yeni bir dille çözmek gerektiğinden emin değilim
    • Ana akım bir dil olmak için, kullanım senaryolarının çoğunu kapsayacak öngörülebilir bir kütüphane ekosistemi gerekir

  • Zig 1.0 olana kadar takip etmenin çok anlamlı olmadığını düşünüyorum
    Mevcut yapı muhtemelen birkaç kez daha baştan yazılacak
    Ben de bir dönem ilgilenmiştim ama hayatım boyunca 1.0’ı görebilecek miyim emin değilim

    • Aslında Zig’deki geriye dönük uyumluluk kırılmaları çoğunlukla standart kütüphanede (stdlib) yaşanıyor
      Dosya G/Ç gibi temel işlevler neredeyse aynı kalıyor, sadece ad alanları değişiyor
      Ben “canlı bir dil”in daha iyi olduğunu düşünüyorum
      1.x sonrasında bile stdlib’i ince tutmak için sürüme göre arayüz yönetim stratejileri olsa iyi olur
    • Zig dilinin kendisini seviyorum ama stdlib kalitesi konusunda soru işaretlerim var
      Kendi I/O çatımı geliştirirken yetersiz test ve hatalı assembly kodu buldum
      Bunu birkaç kez dile getirdim ama düzeltilmedi; bu da güvenimi azalttı
    • Büyük ölçekli projelerde tereddüt yaratabilir ama Zig şimdiden ticari olarak değerli
      Özellikle bulut ortamlarında performans optimizasyonuyla sunucu maliyetlerini %90’dan fazla azaltabiliyor
      Python ya da Node ile bir yere kadar gidilebiliyor; sonunda C, C++, Rust ya da Zig’den birine inmek gerekiyor
      Bunlar arasında Zig öğrenmesi kolay, okuması ve test etmesi rahat
    • Bu arada Bun da Zig ile yazıldı
      Yani zaten üretim düzeyinde kullanılan bir dil
    • Bizim ekip (ZML), std.Io’nun gelmesinden sonra Zig’in master branch’ini sürekli takip ediyor
      Değişikliklerin çoğu gerçekten dilin iyileşmesi gibi hissettiriyor

  • Rust’ın io_uring desteği hâlâ tamamlanmamışken Zig’in önce bunu uygulamaya çalışması ilginç
    Rust’ta güvenli ve zero-cost soyutlamalar tasarlamak zor

  • Bu haber aslında hâlâ tamamlanmamış bir uygulama ile ilgili
    Örneğin GCD sürümünde ağ desteği yok
    Arayüz giderek büyüyor; tamamlanmış bir yapıdan çok mevcut anlık görüntüye benziyor

    • Ama yazının girişinde bunun deneysel aşamada olduğu zaten belirtilmişti
      Ayrıca ileride yapılması gereken 6 ana görev de somut biçimde sıralanmıştı

  • Yığın belleği optimizasyonuyla ilgili bir issue var
    Farklı bloklarda [500]u8 kullanılsa bile stack frame’de yalnızca 500 bayt yer kaplamasını sağlayacak bir özelliğe ihtiyaç var
    Bu özellikle green thread coroutine stack bağlamında önemli

  • Zig’in sürekli iyileştirme çabasına olumlu bakıyorum
    Şu anda io_uringi gerçekten iyi ele alan bir dil yok
    Zig bunu iyi çözerse büyük bir avantaj elde eder
    İstikrardan çok öğrenme ve deneye önem veren yaklaşımın daha değerli olduğunu düşünüyorum

    • Düşük seviyeli bir dilde bile async istemeleri ilginç
      Ben Zig’de libxev kullanarak io_uringi doğrudan kontrol etmeyi tercih ediyorum
    • Ben de olumlu bakıyorum ama Zig’in C gibi bir uzun vadeli destek sürümü (LTS) ne zaman çıkaracağını merak ediyorum
      C’nin başarısının ana nedenlerinden biri istikrarı ve tutarlı geliştirme kültürüydü

  • Zig’in freestanding target konusunu ciddiye alması hoşuma gidiyor
    0.16 sürümünde kod yeniden kullanılabilirliğinin daha da artmasını bekliyorum

  • macOS’in iç taraflarına uzun zaman sonra yeniden baktım; GCD’yi korumuş olmaları sevindirici
    Bunun paralelleştirme için dengeli bir yaklaşım olduğunu düşünüyorum

  • Diğer diller tartışmakla oyalanırken Zig doğrudan deniyor ve gerekirse geri alıyor
    Gerçek dünyada sınanmış API’lerin en iyi tasarım olduğuna inanıyorum
    Eski sürümleri kullanmaya devam edebilirsiniz; en yeni sürüme geçerseniz daha temiz ve daha hızlı araçlar elde edersiniz

    • Jai, oyun geliştirmeye odaklandığı için genellik ve güvenlik açısından eksik kalıyor
      C++ kadar karmaşık ama Zig, C düzeyindeki sadeliği koruyor
      Carbon ise hâlâ ortada somut bir şey olmayan bir durumda
    • Zig’i 1.0 değil diye eleştirmek tuhaf
      Jai 11 yıldır kapalı betada; Zig ise zaten birçok gerçek projede kullanılıyor
    • Bir dilin gerekirse 20 yılda ama düzgün şekilde tamamlanması daha iyi
      Python 2→3, Rust async, Go generics, C++ gibi örneklerde gördüğümüz kontrolsüz değişimler daha zararlı olabiliyor