LLVM ile boşanma başvurusu

 (github.com/ziglang)
2 puan yazan GN⁺ 2023-07-01 | 2 yorum | WhatsApp'ta paylaş
  • Zig projesi, ana zig çalıştırılabilir dosyasından LLVM, Clang ve LLD kütüphane bağımlılıklarını tamamen kaldırmayı hedefliyor
  • Kalan işler LLD’nin kaldırılması, LLVM API çağrılarının kaldırılması, C/x86/wasm/aarch64 backend’lerinde ilerleme, Clang’e bağımlı alt komutların ve önişlemci kullanımının kaldırılması, zig ar için alternatif bir uygulama gibi başlıklara ayrılıyor
  • LLVM backend’i hâlihazırda .bc dosyası üretiyor; ancak Zig derleyicisi .bc dosyalarını nesne dosyasına derleme yeteneğine sahip olmayacak ve bu durumda Clang’in ayrı kurulması gerekecek
  • Beklenen etkiler arasında kaynak koddan derleme ve bootstrap sürecinin basitleşmesi, Linux dağıtımları ve Homebrew’de LLVM/Clang/LLD ile ilgili sorunlardan kaçınılması, ikili dosya boyutunun yaklaşık 150 MiB → 5 MiB düşmesi yer alıyor
  • Zig’in kendi optimizasyon geçişlerini uygulayabileceği ve alive2 gibi araştırma projeleri ile Intel, ARM, RISC-V çip üreticilerinden doğrudan katkı çekebileceği yönü öne çıkarılıyor

Zig çalıştırılabilir dosyasından kaldırılmak istenen bağımlılıklar

  • Bu issue’nun amacı, Zig projesinden LLVM, Clang, LLD kütüphanelerini tamamen kaldırmak
  • Kalan bağlantı noktaları LLD, LLVM, Clang ve zig ar alanları olarak düzenlenmiş

LLD ile ilgili kalan işler

LLVM ile ilgili kalan işler

Clang ile ilgili kalan işler

zig ar ve .bc dosya işleme kısıtları

  • zig ar: a drop-in llvm-ar replacement #9828: zig ar’ı llvm-ar muadili hâline getirme işi devam ediyor
  • LLVM backend’i hâlihazırda .bc dosyaları üretiyor; ancak Zig derleyicisi .bc dosyalarını nesne dosyasına derleme yeteneğine sahip olmayacak
  • Bu kullanım senaryosunu karşılamak için Clang’in ayrıca kurulması gerekecek

Bağımlılıkların kaldırılmasıyla beklenen değişiklikler

  • Zig tarafındaki tüm hatalar Zig projesinin sorumluluk alanına girecek
  • Derleyiciyi kaynak koddan derleme ve bootstrap etme süreci basitleşecek; host sistemde yalnızca C derleyicisi yeterli olacak
  • Linux dağıtımları ve Homebrew gibi paket yöneticilerinin LLVM, Clang ve LLD ile ilgili oluşturduğu sorunlarla artık uğraşılmayacak
  • Zig derleyici ikilisinin boyutu yaklaşık 150 MiB’den 5 MiB’ye düşecek
  • Derleme hızı birkaç basamak mertebesinde artabilir
  • Zig, kendi optimizasyon geçişlerini uygulayarak bilişimin en ileri seviyesini yukarı taşıyabilir
  • alive2 gibi araştırma projelerini çekebilir
  • Intel, ARM, RISC-V çip üreticileri gibi kendi CPU’larında daha iyi makine kodu isteyen paydaşların doğrudan katkısını teşvik edebilir

İlgili okumalar

2 yorum

 
alstjr7375 2023-07-02

LLVM kadar optimizasyon veya platform desteği mümkün olur mu..
 
GN⁺ 2023-07-01
Hacker News görüşleri

  • Andrew o kadar keskin biri ki, bu bir hedef olarak ilan edildiyse ekibin sonunda bunu başaracak gibi görünüyor
    Ama Zig'in LLVM ile yaşadığı zorlukları çok iyi bilmeyen biri olarak bakınca, bu karar ekibin kapasitesini Zig'in kendisinden alıp binutils benzeri çevre araçlara yönlendiriyormuş gibi görünüyor
    Başlığı ilk gördüğümde derleyiciyi bırakıyorlar sandım; ayrıca Zig gibi bir proje için LLVM'i korumanın da önemli getirileri var gibi duruyor
    Yine de LLVM içindeki pek çok kodu C++ yerine Zig ile yeniden yazma fikri oldukça havalı ve iddialı. Hatta LLVM'i yaratan Lattner'ın girişimi kadar iddialı olduğu da söylenebilir
    Ama yanlışlıkla ikinci dereceden zaman karmaşıklığına düşen kodlar, Zig de LLVM kadar popüler ve faydalı hale gelirse, muhtemelen kaçınılmaz olacaktır

    • Bana bir zamanlar NASA'nın gayriresmî proje yönetimi belgesi gibi görünen bir yazıda okuduğum şu cümleyi hatırlattı
      “Bir uzay görevi mevcut bir fırlatma aracını yeniden kullanmıyorsa, o proje bir fırlatma aracı geliştirme projesine dönüşür; görevin özü sandığınız diğer her şey ise ikincil hale gelir” gibi bir fikirdi
      Hatırladığım ek kısım da, “mevcut fırlatma aracına uymak için taviz vermek yerine belirli göreve uygun bir araç yapmanın daha ucuz ve verimli olacağını düşünebilirsiniz” ön kabulünü içeriyordu
    • Swift'in başarısıyla ilgili yakın tarihli Chris Lattner röportajını hatırlattı. Ona göre başarının nedenlerinden biri, büyük bir Objective-C projesinde hiçbir şeyi baştan yazmadan Swift'i karma şekilde kullanmaya başlayabilmekti
      Rust'ın başarısının bir kısmı da C/C++ ile benzer uyumluluğa dayanıyor
      Zig'in benzer bir yetenek olmadan başarılı olmasını hayal etmek zor; bu yüzden umarım bu kilometre taşını aynen zorlamazlar
    • LLVM ile arasında büyük bir fark var. En azından Apple'ın projeyi devraldığı bağlamda pek seçenek yoktu
      Çünkü GCC, Apple'ın istediği ya da ihtiyaç duyduğu şeyleri ya izin vermiyor ya da hayata geçirmek istemiyordu
    • “Hedef olarak ilan edildi” denemez. Bu hâlâ kabul edilmemiş bir öneri
    • binutils, taşınabilir biçimde ikili kod formatlarını ele alan genel amaçlı bir araçlar paketine daha yakın; derleyicinin bunun yarısına, özellikle de eski miras kısmına ihtiyacı yok
      TCC'deki gibi daha odaklı olunursa işin çoğu çoklu mimarilere kod üretimi tarafında olacaktır

  • Burada iki sorun var. Biri kod üretimi, diğeri ise bootstrap
    Deneyimime göre derleyicinin optimizasyon pass'lerini yazmak kolay ve eğlencelidir. Register allocation ve SSA biçimini anlamak için makale okumak gerekir, ama IR'yi çeşitli optimizasyon pass'lerinden geçirip adım adım rafine eden kodu yazmak keyiflidir
    LLVM olmadan da yüksek kaliteli optimizasyon pass'leri yapılabilir. Ama IR'yi makine koduna doğrusal hale getirme aşaması, “mov [eax+8*ebx], 123” komutunun x86-32/64 üzerinde kodlanmasının bütün yollarını sevmiyorsanız, sıkıcı ve sıradan bir iştir
    İkili boyutunu optimize ediyorsanız hangi platformda “push eax; push eax; push eax”ın “add rsp,12”dan daha kısa olduğunu ölçmek ister misiniz? Bu sadece x86 hikâyesi; bunu çoğu geliştirici için önemsiz olan x86 dışı mimarilerle çarpınca mesele çok daha büyüyor
    Seyrek kullanılan mimariler için yazılmış kod üreticilerindeki büyük hataların yıllarca fark edilmemesi ihtimali de oldukça yüksek
    İkinci konu bootstrap. Zig ile yazılmış Zig derleyicisini neyle derleyeceksiniz? Örneğin C ile yazılmış, optimize edilmemiş minimal bir Zig derleyicisiyle Zig derleyicisini derleyebilirsiniz
    Ama optimize edilmemişse, sonra Zig derleyicisini optimize edilmiş Zig derleyicisiyle yeniden derlemeniz gerekir. Çözümsüz bir problem değil ama uzun ve karmaşık build süreci potansiyel katkıcıları kaçırma riski taşır

  • Zig'in C'yi, belki C++'ı bile derleyebildiği bu kadar pazarlanmışken şimdi LLVM'i tamamen çıkaracağız demek oldukça radikal görünüyor
    Destek vermeye çok daha fazla insan katılmadıkça LLVM düzeyinde platform desteğine yaklaşma ihtimali de çok düşük görünüyor
    İsteyenler için kendi backend'lerini ekleme planını anlayabilirim ama LLVM'i tamamen kaldırmak aceleci görünüyor

    • Eğer çalışma çoktan başlamış olsaydı aceleci denebilirdi, ama issue tracker'da “accepted” etiketi taşımayan diğer öneriler gibi bu da şu an sadece tartışma ve karşı öneri toplama aşamasında
      Şu anda ekip geri bildirim topluyor, etkilenen kullanım senaryolarını öğreniyor ve uygulanabilirliği ölçmeye çalışıyor; bu yüzden buna aceleciliğin tam tersi bile denebilir
    • Bağlantı verilen issue'nun gövdesini okursanız LLVM backend'inin tamamen kaldırılmadığını görürsünüz. Sadece ana ikiliden ayrılıyor; sistemde LLVM kuruluysa backend olarak yine kolayca kullanılabiliyor
      Genel durumda gerekmeyen 100MB+ boyutunda bir LLVM kopyasını paketle birlikte sunmak zaten biraz tuhaf, o yüzden mantıklı. Geliştiriciyseniz muhtemelen zaten kurmuşsunuzdur
      Yine de kurulu Zig'in sistemdeki LLVM sürümüyle düzgün çalışacağını garanti etmek zor olabilir. Bekleyip görmek lazım
    • Hâlâ LLVM bitcode üretiyor, ama artık LLVM kütüphanelerine bağımlı olmayacak
      https://github.com/ziglang/zig/issues/13265
    • Ben de tam olarak öyle anladım
      Son zamanlarda Zig hakkında biraz daha okudum, hatta sistem paketleriyle boğuşmadan LLVM ile C++ derlemenin kolay bir yolu olarak denedim. C/C++'tan Zig'e geçebilme fikri büyük bir satış noktasıydı
      Çok ani ve beklenmedik geldi. Proje için doğru mu yanlış mı bilmiyorum ama benim açımdan gerçekten durup dururken olmuş gibi hissettiriyor
    • Bir Rust projesinde Zig'i C++ derleyicisi olarak kullanıyorum. Çünkü GitHub Actions üzerinde çapraz derleme yapmanın en az acı veren yolu buydu

  • Bir yandan bağımlılıkları azaltmaya yönelik bu titiz isteğe saygı duyuyorum, ama bedeli epey ağır görünüyor
    C++ uyumluluğunun kaybı, çevremdeki Zig hayranlarının en çok andığı avantajlardan birini fiilen ortadan kaldırıyor
    Performans kaybı da, geçici olsa bile, onların birlikte andığı bir diğer temel nokta

    • Tepkilerin çoğu bu öneriye karşı gibi görünüyor
      Hızlıca göz atanlar için söyleyeyim: Bu kararlaştırılmış bir şey değil, bir öneri

  • Yaklaşık 4 yıldır gömülü projeleri ve kütüphaneleri tamamen Zig ile yazdım; şimdi birkaç tier 1 desteklenen mimari öylece mi çıkarılacak?
    Dil onlara ait, istedikleri gibi yapabilirler ama öyleyse markalamayı da buna göre ayarlasalar iyi olur

    • Gerçekten çıkarılıyor mu?
      Sanırım tier 1 desteği iki kategoriye ayrılacak: yerleşik tier 1 desteği ve isteğe bağlı LLVM backend’i üzerinden tier 1 desteği.
      Bir mimaride zaten tier 1 desteği varsa, LLVM backend’ini isteğe bağlı bağımlılık haline getirmek o desteğin kaybolması için bir sebep gibi görünmüyor.
      Andrew’un teklifte yazdığı gibi, bu yaklaşım daha nadir mimarileri daha iyi desteklemenin yolu da olabilir. İlginç işlemci mimarileri için bir Zig backend’i üzerinde seve seve çalışırım ama LLVM’ye asla katkı yapmam. C++ ile çalışmak hobi olarak yapılacak bir şey değil.
    • LLVM’nin yaptığı her şeyi kendi yöntemleriyle yeniden uygulayıp sonra LLVM’yi çıkarmayı mı düşünüyorlar?
      Bunun faydası ne olacak? Bu kaynak israfı değil mi?
    • Zig’in 1.0 öncesinde olduğu da bir sır değil. Bunun sorumluluğunu tamamen onlara yüklemek zor ama yine de oldukça radikal bir öneri gibi görünüyor.
    • Bu daha sadece öneri aşamasında. GitHub issue’su da esas olarak lehte/aleyhte kullanım örnekleri vb. paylaşmak için var; Accepted değil.
    • Bu hâlâ bir öneri olduğu için, yeterince çok kişi görüş bildirirse — ki zaten birçok kişi bunu yapıyor — çekirdek ekibin de yaklaşımını ayarlayacağını düşünüyorum.

  • DLang’in 3 derleyicisi var.
    gdc, Gnu Compiler Collection backend’i tabanlı; ldc, LLVM backend’i tabanlı; dmd ise benim Zortech/Symantec/Digital Mars için yazdığım x86 kod üreticisi tabanlı.
    Her birinin artıları, eksileri ve hedefleri farklı ama destekledikleri D dili aynı.
    Genel olarak kullanıcılar seçenekleri seviyor ve bazıları birden fazlasını birlikte de kullanıyor.

    • İlginç bir yaklaşım farkı var. D tamamen ayrı derleyicilere sahip gibi görünüyor ama Zig’in yönü, kuruluysa ana Zig derleyicisinin LLVM’yi backend olarak desteklemesi gibi görünüyor.
      Eğer doğru anladıysam Zig’in yaklaşımını beğeniyorum.
    • Birden fazla derleyicisi olan bir başka dil de Common Lisp. Ticari olanlar da var ama çoğu ücretsiz olan, üretime hazır yaklaşık on derleyici bulunuyor.
      Bu sayede geliştirme sırasında en hızlı derleyiciyi, son sürüm içinse en hızlı çalışma zamanı ya da en düşük bellek kullanımı olan derleyiciyi seçebilmek çok faydalı oluyor.
      Ayrıca tüm derleyicilerin uyduğu bir dil spesifikasyonu varsa, bu dilin istikrarlı olduğuna ve alttan bir anda bozulmayacağına dair güvence sağlıyor.
      Elbette Zig gibi, henüz istenen şeyleri değiştirip dili daha tutarlı, daha temiz ve daha güçlü hâle getirebilen dillerin de avantajı var. Yine de bugünlerde böyle bir istikrara çok daha fazla değer veriyorum; çünkü geliştirme araçlarını sürekli yakalamaya çalışmak yerine kullanıcıya gerçek değer üretmeye odaklanabiliyorsunuz.
    • İleri düzey kullanıcılar için seçeneklerin olması bir avantaj ama seçmek zorunda olmak başlı başına büyük bir dezavantaj bence.
    • Kullanıcıların seçenekleri sevdiğini anlıyorum ama Zig uzun vadede geniş benimsenme hedefliyorsa, DLang’in iyi bir emsal olduğunu düşünmüyorum.

  • Zig’i ilginç kılan başlıca nedenlerden biri, C/C++ derleyicisinin yerine doğrudan takılabilmesiydi.
    Arkadaşlarım, Windows’ta Zig’i C/C++ derleyicisi olarak kurmanın diğer tüm alternatiflerden daha kolay olduğunu söylüyordu.
    Bu öneri kabul edilirse kişisel olarak Zig’in popülaritesinin Hare ya da diğer aşırı niş diller seviyesine düşeceğini düşünüyorum.
    İş arkadaşlarımı Zig’i bir kez bile denemeye ikna edebilmek için Uber’in bunu production’da kullandığına dair yazıları bile göndermek zorunda kaldım. Mevcut projelere anında değer katmasaydı, iş arkadaşlarım ikinci kez düşünmezdi bile.
    Yine de önerinin arkasındaki gerekçeyi anlıyorum. LLVM derleme süreleri korkunç gelebiliyor ve özel bir bytecode’a sahip olmak güzel optimizasyon teknikleri uygulamayı mümkün kılabilir. LLVM bug’larıyla uğraşmak da pratikte el sürmesi zor bir iş ve Julia ekosisteminde de bunu gördüm.
    Tavsiyemin bir anlamı olacaksa, bence Zig 1) debug build’lerde hızlı derleme ve hızlı debug için özel bytecode, 2) release build’lerde hızlı çalışma zamanı performansı için LLVM kullanmalı.
    C/C++ cross-compilation desteğini koruyarak 1)’i başarabiliyorsa — örneğin sadece o kısmı LLVM’ye devrederek — ek backend kodu bakımının getireceği trade-off’a rağmen bu en iyi uzlaşma olabilir.

    • Julia ekosisteminde LLVM bug’larıyla uğraşan kişilerden biri olarak söyleyebilirim ki, evet.
      Bu, üst düzey Julia derleyicisi çalışmasından farklı ayrı bir beceri seti gerektiriyor ve hata düzeltmelerini upstream’e birleştirmek bazen uzun sürebiliyor.
      Ama gerçekte upstream ile oldukça iyi ve üretken bir ilişkimiz var; LLVM’yi kaldırmaya karar verseydik proje çok daha az iş başarabilirdi.
      Özellikle GPU desteği ve HPC desteği, örneğin PPC, LLVM’ye dayanıyor.
      Bu yüzden Julia’nın bizim patch set’imize/fork’umuza uygun biçimde derlenmesi yönündeki tavrımızı koruyoruz ve bu patch’leri kullanmayan Julia build’lerinde ortaya çıkan bug’lara zaman harcamıyoruz. Özellikle dağıtım build’lerinde bu sık oluyor.

  • Başka dillerin LLVM dışı backend çalışmalarını izlemiş biri olarak, bağlantısı verilen teklifte kibir çok güçlü hissediliyor.
    Yazarı o kişi olmasaydı bunu, Zig’e yeni başlamış birinin gelişigüzel açtığı bir GitHub issue’su sanardım.
    Gerekli iş miktarını küçümsüyor, LLVM’ye konmuş bütün emeği üstü kapalı biçimde küçültüyor ve “bunu elbette daha ucuza, daha hızlı, daha iyi yaparız” türü bir özgüven ve maço tavır her cümleye sinmiş durumda. Hayal kırıklığı yaratıyor.
    Andrew’un bugüne kadarki çalışmalarına gerçekten saygı duydum; bu yüzden bunu aceleyle ya da anlık bir dürtüyle yazmış ve böyle okunacağını fark etmemiş olabilir diye iyi niyetli yaklaşmak istiyorum.
    Ama bu yazı güven vermiyor ya da önerinin kendisine daha açık fikirli bakmamı sağlamıyor.

    • LLVM backend’i hakkında hiçbir şey bilmiyorum ama kullanıcı sorunlarının %100’ünü çözmeye çalışan kütüphaneler, sonunda daha optimize alternatiflere göre daha hantal ve yavaş olma eğiliminde olur.
      Webpack ve esbuild bunun örnekleri.

  • LLVM olmadan bir şeyler inşa etmek için doğru zaman birkaç yıl önceydi. Ama şimdi C++ özelliklerini çıkarırlarsa bu Zig’in sonu olabilir.
    Bunu aşamalı olarak kaldırmak yerine Zig ile kendi C++ derleyicilerini yazma planını duyurmamış olmalarına şaşırdım.

    • Sadece bir C++ parser yazmak bile devasa bir proje.
      18. yaş gününde başlayan bir bireyin bir C++ derleyicisi yazabileceğinden bile emin değilim. Çalışan bir derleyici yapmaya yetecek kadar ömrü kalmayabilir.

  • Zig, dünyanın yeni C’si olmak istiyor; dünyanın yeni C++’ı olmak istemesi ise pek söz konusu değil
    Bu öneride de C çapraz derleme desteğinin sürmeye devam ettiğini görebilirsiniz
    Bu tercih doğru olabilir. C şu anda gömülü dünyada çok kullanılıyor ve o alanda LLVM iyi değil
    Ben Zig olsaydım tüm mikrodenetleyicileri hedeflemek isterdim ve bunu başarmanın gerçekçi yolu yalnızca bu