mold 2.0.0 - linker berkecepatan tinggi

• Lisensi berubah dari AGPL ke MIT, menjadi perubahan utama di mold 2.0.0
• Perbaikan bug yang membuat file objek dengan lebih dari 65520 section tidak dapat dibuat saat menggunakan --relocatable
• -undefined kini ditafsirkan sebagai sinonim dari --undefined, bukan -u ndefined, sehingga selaras dengan perilaku GNU linkers dan LLVM lld
• -nopie diperlakukan sebagai sinonim dari --no-pie
• Dukungan tipe relokasi R_RISCV_SET_ULEB128 dan R_RISCV_SUB_ULEB128 pada RISC-V
• Dukungan tipe relokasi R_PPC64_REL32 pada PPC64

[GN⁺]

Pendapat di Hacker News

• mold benar-benar karya yang luar biasa untuk sistem modern.
  Saat mencoba membuat build proyek terbaru jadi lebih cepat, saya sadar tahap linking adalah bottleneck yang sangat besar. Meski memakai 24 core * 2 thread, sekitar 30% performa total menganggur karena linker.
  Dulu pernah mencoba build dengan mold, tapi saat itu tidak berjalan baik; saya berencana mencobanya lagi.

  • Mold memang hebat. Beberapa bulan lalu saat mengutak-atik O3DE, saya beralih ke Mold untuk melihat apakah siklus build-run bisa dipersingkat, dan hasilnya jelas lebih cepat.
    Saya tidak ingat angka pastinya, tapi perbedaannya cukup besar: yang di gold dan lld memakan beberapa detik turun menjadi di bawah 1 detik dengan mold.
  • Di kantor kami juga melakukan beberapa proof of concept, dan pada mesin build uji yang kecil, waktu build penuh untuk lapisan UI turun dari 44–45 menit menjadi 29 menit setelah beralih dari lld ke mold.
    Itu kode C++/Qt yang kompleks.
  • mold -run ninja bekerja sangat baik di lingkungan saya.

• Saya sangat senang melihat kabar perubahan lisensi ini. Saya berharap proyek ini juga bisa menghasilkan uang, tetapi dengan lisensi MIT, kemungkinan untuk mengintegrasikannya ke proyek kerja menjadi jauh lebih besar.
  Kalau kami benar-benar memakainya, saya akan mencoba meyakinkan perusahaan untuk mensponsori proyek ini.

  • Lisensi linker semestinya tidak terlalu jadi masalah. Ia tidak menyuntikkan kode berhak cipta, dan di ekosistem GPL pun sudah ada preseden bahwa boilerplate kecil dianggap pengecualian, jadi tidak ada alasan binary yang dihasilkan terkena dampak lisensi copyleft dari alatnya.
    AGPL pun hanya akan membatasi saat linker yang dimodifikasi secara privat didistribusikan sebagai layanan jaringan, yang bukan skenario realistis untuk tool pengembangan dasar.

• Saya penasaran dengan perubahan lisensinya. Bukankah ini file executable? Karena memanggilnya sebagai proses terpisah tidak membuat software yang memanggilnya harus menjadi GPL, dalam kasus umum peralihan ke MIT semestinya tidak berdampak.
  Jika para penulis benar-benar menginginkan lisensi yang lebih permisif, alih-alih melisensikan ulang dari AGPL ke MIT, mereka seharusnya beralih ke AGPL dengan pengecualian linking. Contoh proyek GPL dengan pengecualian linking adalah libgit2: https://github.com/libgit2/libgit2#license
  Lisensi seperti ini lebih permisif, tetapi tetap memungkinkan mereka menjual lisensi komersial kepada pihak yang membuat perubahan closed source.

  • Intinya tampaknya para penulis tidak ingin terus menjual lisensi. Sepertinya nilainya tidak sebanding dengan kerepotannya.
    Versi macOS, sold, tampaknya pengecualian.

• Linker ini secara nyata meningkatkan kepuasan pengembangan di repositori Rust eksplorasi saya yang sedang berkembang menjadi monolit web besar memakai SeaORM dan axum/tokio.
  Anda mungkin tidak ingin tahu ukuran direktori target saya, tetapi incremental build terasa jauh lebih gesit.

  • Saya perlu mencoba-coba mold.
    15:55 $ du -Hs --si target/
11G target/

• Mold luar biasa, dan ada beberapa penggunaan favorit saya.

  1. Build Rust jadi lebih cepat
     [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=-fuse-ld=mold",
"-C", "target-cpu=native"
]
  2. Di ArchLinux, menambahkan "-fuse-ld=mold" ke CFLAGS juga membuat makepkg lebih cepat.
  • Apakah ada cara menimpa konfigurasi linker ini hanya untuk instalasi lokal? Saya tidak ingin mengubah kode produksi atau binary, tapi akan bagus kalau build bisa lebih cepat.
  • Saya penasaran seberapa besar perubahan waktu linking Rust sebelum dan sesudahnya.
  • Bagaimana rilis terbaru ini dibandingkan dengan lld? Apakah bisa berjalan juga di alpine/musl?

• Keputusan yang sangat bijak. Kadang ada momen sulit ketika saya harus mengakui bahwa beberapa hal dalam produk atau kode saya tidak cocok untuk dimonetisasi.
  Pasarlah yang memberi tahu, dan meski disayangkan, yang penting adalah mencari hal lain yang dihargai pasar daripada melawannya.

• Ada yang tahu apakah perubahan lisensi/strategi bisnis ini juga akan diterapkan ke sold? sold adalah mold untuk macOS.
  https://github.com/bluewhalesystems/sold

  • Apple punya linker paralel baru, mungkin saja menarik atau mungkin juga tidak.
    https://twitter.com/davidecci/status/1665835119331135488
  • Kalau melihat bagian paling atas README mold, dugaan saya itu tidak akan menjadi open source.
    “Repositori ini berisi versi gratis dari linker mold. Jika Anda mencari versi komersial yang mendukung macOS, kunjungi repositori linker sold.”
  • Saya tidak paham kenapa Apple tidak mensponsori proyek ini dan menjadikannya linker default Xcode.
    Tinggal bayar besar untuk pekerjaannya dan membuat dunia lebih baik, bukan?
    Itu seharusnya sangat mudah bagi Apple.

• Lisensinya berubah dari AGPL ke MIT.
  Tapi bagaimana pengrajin sehebat ini seharusnya diberi kompensasi, dan mengapa itu belum terjadi? Rasanya perusahaan, terlepas dari ukurannya, perlu mengalokasikan sejumlah anggaran untuk dependensi atau tool inti dan mempublikasikannya di situs web resmi mereka. Sepertinya kita membutuhkan semacam norma budaya seperti itu.

• Saya sempat lupa bahwa ini adalah linker yang cepat
  “Mold 2.0.0 adalah rilis mayor baru dari linker cepat kami. Dalam rilis ini, kami mengubah lisensi dari AGPL ke MIT dengan tujuan memperluas basis pengguna. Seperti yang diketahui oleh mereka yang mengikuti perkembangannya, ini bukan keputusan mudah karena kami telah mencoba memonetisasi produk dengan skema lisensi ganda AGPL/lisensi komersial. Sayangnya, pendekatan ini tidak memenuhi ekspektasi. Perubahan lisensi ini adalah hasil dari menerima kenyataan tersebut. Kami tidak ingin terus bersikeras pada strategi yang tidak berjalan dengan baik.”

  • Ada yang ingat masa ketika harus membayar biaya cc di Solaris? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
    Itu mengerikan, dan juga cara yang buruk untuk memperlakukan developer yang menulis software untuk OS mereka sendiri
    Kita sudah sangat lama terbiasa tidak membayar untuk tool pengembangan level rendah, melainkan membayar biaya dukungan. Mengejutkan juga bahwa mereka mencoba lisensi dengan cara seperti itu

• Selama bertahun-tahun saya beberapa kali melihat diskusi tentang linker cepat dan cerita bahwa mengganti satu linker dengan yang lebih cepat membuat waktu kompilasi turun drastis, tetapi biasanya saya tidak benar-benar tahu mengapa linker lambat
  Akan bagus kalau ada yang bisa menjelaskannya

  • Ini bukan penjelasan lengkap, tetapi linking itu CPU-intensive, dan linker lama umumnya single-threaded
    Sebagian besar peningkatan performa berasal dari memproses pekerjaan secara paralel, dan pada CPU multicore modern yang kuat, ini menghasilkan peningkatan besar
    Jika ingin tahu lebih lanjut, ada presentasi bagus dari Rui tentang Mold: https://www.youtube.com/watch?v=hAt3kCalE0Y
  • Dalam kondisi ideal, linker seharusnya secepat cat. Tinggal menyambungkan binary lalu selesai. Pada masa disk berputar, I/O disk adalah masalahnya, tetapi sekarang sudah lebih berkurang
    Bagian yang memakan waktu adalah pekerjaan menulis ulang isi sambil berjalan. Menelusuri tabel relokasi dan memasukkan alamat ke kode itu murah, dan dead stripping per section juga cukup murah, tetapi untuk melakukan dead stripping pada basic block individual di dalam fungsi dibutuhkan analisis jauh lebih banyak, sehingga memakan waktu
    Deduplication string konstan adalah ide bagus, tetapi semuanya harus dialirkan ke semacam hash table. Jika ingin membuat suffix yang sama ikut dibagikan, pekerjaannya bertambah
    Deduplication, dead stripping, dan penulisan ulang informasi debug juga memakan waktu. Dalam debug build, bisa ada beberapa GB DWARF yang harus ditulis ulang
    Menariknya, fakta bahwa linker bisa diprogram lewat script sehingga kita dapat memberikan program untuk diinterpretasikan tampaknya bukan biaya besar. Mungkin karena script tersebut cukup pendek dan fiturnya juga sampai batas tertentu terbatas
    Secara historis, alasan lld sangat cepat adalah karena ia tidak banyak memproses informasi debug atau melakukan deduplication lain. lld berjalan cepat, tetapi binary keluarannya besar
    Sudah beberapa tahun saya tidak menangani performa linking, jadi saya tidak terlalu tahu kondisi saat ini. Khususnya, saya tidak tahu mold atau lld berada di posisi mana dalam kompromi antara kualitas output dan performanya sendiri
  • Materi terbaik yang pernah saya baca adalah blog Ian Taylor tentang pekerjaannya pada linker gold
    https://www.airs.com/blog/archives/38
    “Sekali lagi, tujuannya adalah kecepatan. Dalam kasus ini, lebih cepat daripada linker kedua saya. Linker itu menjadi jauh lebih lambat selama bertahun-tahun karena ditambahkannya dukungan ELF dan shared library. Dukungan ini tidak dirancang sejak awal, melainkan ditempelkan kemudian. Rencana masa depan untuk linker baru ini juga mencakup dukungan incremental linking, yang juga merupakan cara lain untuk meningkatkan kecepatan.”
    Bayangkan aplikasi pada masa awal Unix. Aplikasi sederhana dengan satu tujuan, mungkin hanya satu file sumber, satu object, hanya perlu link ke libc, dan tidak ada hal seperti shared library
    Setelah itu, fitur-fitur “wajib” ditambahkan dan kode linker tumbuh secara organik. Terutama pada masa ketika disk berputar menjadi bottleneck, kebenaran fitur lebih penting daripada kecepatan