mold 2.0.0 - yüksek hızlı bağlayıcı

 (github.com/rui314)
4 puan yazan GN⁺ 2023-07-28 | 1 yorum | WhatsApp'ta paylaş
  • Lisans AGPL'den MIT'ye geçirildi ve bu, mold 2.0.0'ın başlıca değişikliği oldu
  • --relocatable kullanıldığında 65520'den fazla bölüm içeren nesne dosyası oluşturulamamasına neden olan hata düzeltildi
  • -undefined, -u ndefined yerine --undefined için bir eşanlamlı olarak yorumlanacak şekilde değiştirilerek GNU linkers ve LLVM lld davranışıyla uyumlu hale getirildi
  • -nopie, --no-pie için eşanlamlı olarak ele alınıyor
  • RISC-V üzerinde R_RISCV_SET_ULEB128 ve R_RISCV_SUB_ULEB128 yeniden konumlandırma türleri desteği
  • PPC64 üzerinde R_PPC64_REL32 yeniden konumlandırma türü desteği

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-28
Hacker News yorumları

  • mold, modern sistemler için gerçekten harika bir iş
    Yakın zamanda bir projenin derlemesini hızlandırmaya çalışırken, link aşamasının inanılmaz bir darboğaz olduğunu fark ettim. 24 çekirdek * 2 iş parçacığı kullanmama rağmen linker yüzünden toplam performansın yaklaşık %30'u boşta kalıyor
    Daha önce mold ile derlemeyi denemiştim ama o zaman pek iyi çalışmamıştı; tekrar denemeyi planlıyorum

    • Mold muhteşem. Birkaç ay önce O3DE ile uğraşırken derle-çalıştır döngüsünü kısaltabilir miyim diye Mold'a geçmeyi denedim; kesinlikle hızlandı
      Kesin sayıları hatırlamıyorum ama gold ve lld ile birkaç saniye süren şeyin mold ile 1 saniyenin altına inmesi gibi, epey büyük bir fark vardı
    • Şirkette de birkaç kavram kanıtlama çalışması yaptık; küçük bir test derleme makinesinde UI katmanının tam derleme süresi lld'den mold'a geçince 44–45 dakikadan 29 dakikaya düştü
      Karmaşık bir C++/Qt koduydu
    • mold -run ninja benim ortamımda gayet iyi çalışıyor

  • Lisans değişikliği haberini görmek çok sevindirici. Projenin para da kazanabilmesini umuyorum ama MIT lisansı olursa iş projelerine entegre edilme ihtimali çok daha artar
    Gerçekten kullanmaya başlarsak, şirketi bu projeye sponsor olmaya ikna etmeyi düşünüyorum

    • Linker'ın lisansının pek önem taşımaması gerekir. Telif haklı kod enjekte etmiyor; GPL ekosisteminde de önemsiz boilerplate için istisna sayılan emsaller zaten var, bu yüzden üretilen ikilinin aracın copyleft lisansından etkilenmesi için bir neden yok
      AGPL de ancak özel olarak değiştirilmiş bir linker'ı ağ hizmeti olarak dağıtırken kısıtlama getirir; temel geliştirme araçlarında bu gerçekçi bir senaryo değil

  • Lisans değişikliğini merak ediyorum. Bu bir çalıştırılabilir dosya değil mi? Ayrı bir süreç olarak çağırmak, onu çağıran yazılımı GPL yapmayı gerektirmez; dolayısıyla genel durumda MIT'e geçişin etkisi olmamalı
    Yazarlar gerçekten daha müsamahakâr bir lisans isteseydi, AGPL'den MIT'e yeniden lisanslamak yerine bağlantı istisnası eklenmiş AGPL'ye geçmeliydi. Bağlantı istisnası olan GPL projeye örnek olarak libgit2 var: https://github.com/libgit2/libgit2#license
    Böyle bir lisans daha müsamahakâr olurken, kapalı kaynak değişiklikler yapan taraflara hâlâ ticari lisans satılabilmesini sağlar

    • Esas nokta, yazarların lisans satmaya devam etmek istememesi gibi görünüyor. Uğraşına değmemiş gibi
      macOS sürümü olan sold bunun istisnası gibi duruyor

  • Bu linker, SeaORM ve axum/tokio kullanan büyük bir web monolitine dönüşmeyi hedefleyen keşif amaçlı Rust depomda geliştirme memnuniyetini belirgin şekilde artırdı
    target dizinimin boyutunu bilmek istemezsiniz ama artımlı derlemeler çok daha çevik hale geldi

    • mold'u biraz kurcalamam gerekecek
      15:55 $ du -Hs --si target/
      11G target/

  • Mold harika ve sevdiğim birkaç kullanım alanı var

    1. Rust derlemeleri hızlanıyor
      [target.x86_64-unknown-linux-gnu]
      linker = "clang"
      rustflags = [
      "-C", "link-arg=-fuse-ld=mold",
      "-C", "target-cpu=native"
      ]
    2. ArchLinux'ta CFLAGS'e "-fuse-ld=mold" eklemek makepkg'yi de hızlandırıyor
    • Bu linker ayarını yalnızca yerel kuruluma uygulayacak şekilde geçersiz kılmanın bir yolu var mı? Üretim kodunu veya ikilileri değiştirmek istemiyorum ama derlemenin daha hızlı olması hoş olur
    • Rust link süresinin öncesi ve sonrası ne kadar değiştiğini merak ediyorum
    • Bu en son sürüm lld ile kıyaslandığında nasıl? alpine/musl üzerinde de çalıştırılabiliyor mu?

  • Çok akıllıca bir karar. Kendi ürünümde veya kodumda da bazı şeylerin para kazanmaya uygun olmadığını kabul etmem gereken zor anlar bazen oluyor
    Bunu piyasa söyler; ne yazık ki buna karşı koymaktansa piyasanın ödüllendirdiği başka bir şey bulmak önemli

  • Bu lisans/iş stratejisi değişikliğinin sold için de geçerli olup olmayacağını bilen var mı? sold, macOS için mold demek
    https://github.com/bluewhalesystems/sold

    • Apple'ın yeni bir paralel linker'ı var; ilginizi çekebilir de çekmeyebilir de
      https://twitter.com/davidecci/status/1665835119331135488
    • mold README'sinin en üstüne bakınca, tahminimce açık kaynak olmayacak
      “Bu depo, mold linker'ın ücretsiz sürümünü içerir. macOS'u destekleyen ticari bir sürüm arıyorsanız sold linker deposunu ziyaret edin.”
    • Apple'ın neden bu projeye sponsor olup onu Xcode'un varsayılan linker'ı yapmadığını anlamıyorum
      Yapılan işin karşılığında iyi para ödeyip dünyayı daha iyi bir yer haline getirsinler işte
      Apple için çok kolay bir iş olsa gerek

  • Lisans AGPL'den MIT'e değişti
    Peki bu kadar iyi bir zanaatkâr nasıl ödüllendirilmeli ve neden hâlâ ödüllendirilmiyor? Şirketlerin, ölçekleri ne olursa olsun, temel bağımlılıklara veya araçlara belirli bir bütçe ayırıp bunu resmi web sitelerinde yayımlaması gerekiyor gibi. Bir tür kültürel norma daha fazla ihtiyaç var gibi görünüyor

  • Bunun hızlı bir linker olduğunu unutmuşum
    “Mold 2.0.0, hızlı linker’ımızın yeni majör sürümüdür. Bu sürümde kullanıcı tabanını genişletmeyi hedefleyerek lisansı AGPL’den MIT’ye geçirdik. Süreci takip edenlerin bileceği gibi, ürünü AGPL/ticari lisans şeklinde çift lisanslama modeliyle gelirleştirmeyi deniyorduk; bu yüzden kolay bir karar olmadı. Ne yazık ki bu yaklaşım beklentileri karşılamadı. Lisans değişikliği bu gerçeği kabul etmemizin sonucudur. İyi işlemeyen bir stratejide ısrar etmeye devam etmek istemiyoruz.”

    • Solaris’te cc ücreti ödemek zorunda kalınan zamanları hatırlayan var mı? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
      Berbattı; kendi işletim sistemine yönelik yazılım yazan geliştiricilere davranma biçimi olarak da çok kötüydü
      Çok uzun zamandır düşük seviyeli geliştirme araçları için para ödememeye, bunun yerine destek maliyeti ödemeye alışmış durumdayız. Böyle bir lisanslamayı denemiş olmaları bile şaşırtıcı

  • Uzun süredir hızlı linker’lar hakkındaki tartışmaları ve bir linker’ı daha hızlı olanla değiştirince derleme süresinin ciddi biçimde azaldığını anlatan birçok şeyi gördüm, ama genelde linker’ın neden yavaş olduğunu pek bilmiyordum
    Açıklayabilecek biri olursa iyi olur

    • Tam bir açıklama değil ama linkleme CPU yoğun bir iş ve eski linker’lar genellikle tek iş parçacıklı
      Performans artışının önemli bir kısmı işi paralel yürütmekten geliyor; modern, güçlü çok çekirdekli CPU’larda bu büyük bir iyileşmeye dönüşüyor
      Daha fazlasını öğrenmek isterseniz Rui’nin Mold hakkında iyi bir sunumu var: https://www.youtube.com/watch?v=hAt3kCalE0Y
    • İdeal durumda linker cat kadar hızlı olmalı. İkili dosyaları birbirine ekleyip bitirmesi yeterli çünkü. Döner disklerin kullanıldığı dönemde sorun disk G/Ç’siydi, ama bugün bu daha az önemli
      Zaman alan kısım, ilerlerken içerikleri yeniden yazmak. Yeniden konumlandırma tablolarını dolaşıp koda adresleri yerleştirmek ucuz; bölüm bazında dead stripping de epey ucuz, ama fonksiyon içindeki tek tek temel blokları dead stripping yapmak çok daha fazla analiz gerektiriyor ve zaman alıyor
      Sabit dizge tekilleştirme iyi bir fikir, ama hepsini bir tür hash tablosuna akıtmak gerekiyor. Ortak soneklerin de paylaşılmasını istiyorsanız iş daha da artıyor
      Tekilleştirme, dead stripping ve debug bilgisini yeniden yazmak da zaman alıyor. Debug derlemelerinde yeniden yazılması gereken birkaç GB DWARF bulunabilir
      İlginç biçimde, linker’ın betiklenebilir olması ve yorumlayacağı bir program verilebilmesi büyük bir maliyet gibi görünmüyor. Muhtemelen bunun nedeni ilgili betiklerin oldukça kısa olması ve işlevlerinin de bir ölçüde sınırlı kalması
      Tarihsel olarak lld’nin çok hızlı olmasının nedeni, debug bilgisi işleme veya başka tekilleştirme işlemlerini pek yapmamasıydı. lld hızlı çalışıyordu ama çıktı ikilisi büyüktü
      Link performansı tarafıyla uğraşmayı bırakalı birkaç yıl oldu, bu yüzden mevcut durumu pek bilmiyorum. Özellikle mold veya lld’nin çıktı kalitesi ile kendi performansı arasında nerede durduğunu bilmiyorum
    • Okuduğum en iyi kaynak, Ian Taylor’ın gold linker çalışması hakkında yazdığı blogdu
      https://www.airs.com/blog/archives/38
      “Yine söylüyorum, hedef hız. Bu durumda ikinci linker’ımdan daha hızlı olmak. O linker, ELF ve paylaşımlı kütüphane desteği eklendikçe yıllar içinde epey yavaşladı. Bu destek baştan tasarlanmış değildi; sonradan eklenmişti. Yeni linker için gelecekteki planlar arasında incremental linking desteği de var; bu da hızı artırmanın başka bir yolu.”
      Erken Unix dönemindeki uygulamaları düşünmek yeterli. Basit, tek amaçlı uygulamalardı; muhtemelen tek bir kaynak dosyası, tek bir object dosyası ve yalnızca libc linkleniyordu, paylaşımlı kütüphane gibi şeyler yoktu
      Sonrasında “zorunlu” özellikler eklendikçe linker kodu organik biçimde büyüdü. Özellikle döner disklerin darboğaz olduğu dönemlerde, hızdan çok özelliklerin doğruluğu önemliydi