Mengajukan perceraian dengan LLVM

 (github.com/ziglang)
2 poin oleh GN⁺ 2023-07-01 | 2 komentar | Bagikan ke WhatsApp
  • Proyek Zig bertujuan untuk sepenuhnya menghapus ketergantungan pada library LLVM, Clang, dan LLD dari file executable zig utama
  • Pekerjaan yang tersisa terbagi menjadi penghapusan LLD, penghapusan pemanggilan API LLVM, kemajuan backend C/x86/wasm/aarch64, penghapusan subperintah yang bergantung pada Clang dan penggunaan preprocessor, serta implementasi pengganti zig ar
  • Backend LLVM sudah dapat menghasilkan file .bc, tetapi compiler Zig tidak lagi akan memiliki kemampuan untuk mengompilasi .bc menjadi file objek, sehingga dalam kasus ini diperlukan instalasi Clang terpisah
  • Dampak yang diharapkan mencakup penyederhanaan build dari source dan bootstrap, menghindari masalah terkait LLVM/Clang/LLD pada distribusi Linux dan Homebrew, serta pengurangan ukuran biner dari sekitar 150 MiB → 5 MiB
  • Zig juga mengusung arah agar dapat mengimplementasikan optimization pass sendiri serta menarik kontribusi langsung dari proyek riset seperti alive2 dan produsen chip Intel, ARM, dan RISC-V

Ketergantungan yang ingin dihapus dari executable Zig

  • Tujuan issue ini adalah menghapus sepenuhnya library LLVM, Clang, dan LLD dari proyek Zig
  • Titik keterkaitan yang masih tersisa diringkas ke area LLD, LLVM, Clang, dan zig ar

Pekerjaan tersisa terkait LLD

Pekerjaan tersisa terkait LLVM

Pekerjaan tersisa terkait Clang

zig ar dan batasan pemrosesan file .bc

  • zig ar: a drop-in llvm-ar replacement #9828: Masih ada pekerjaan untuk menjadikan zig ar sebagai pengganti llvm-ar
  • Backend LLVM sudah dapat menghasilkan file .bc, tetapi compiler Zig tidak lagi akan memiliki kemampuan untuk mengompilasi file .bc menjadi file objek
  • Untuk menangani use case ini, Clang harus diinstal secara terpisah

Perubahan yang diharapkan dari penghapusan ketergantungan

  • Semua bug di sisi Zig akan masuk sepenuhnya ke dalam lingkup tanggung jawab proyek Zig
  • Proses membangun compiler dari source dan bootstrap menjadi lebih sederhana, dan sistem host hanya memerlukan compiler C
  • Distribusi Linux dan package manager seperti Homebrew tidak lagi perlu menangani masalah yang mereka timbulkan terkait LLVM, Clang, dan LLD
  • Ukuran biner compiler Zig berkurang dari sekitar 150 MiB menjadi 5 MiB
  • Kecepatan kompilasi berpotensi meningkat dengan skala beberapa digit
  • Zig dapat mengimplementasikan optimization pass sendiri untuk mendorong kemajuan state of the art dalam komputasi
  • Dapat menarik proyek riset seperti alive2
  • Dapat mendorong kontribusi langsung dari para pemangku kepentingan yang menginginkan machine code lebih baik untuk CPU mereka sendiri, seperti produsen chip Intel, ARM, dan RISC-V

Bacaan terkait

2 komentar

 
alstjr7375 2023-07-02

Apakah optimisasi dan dukungan platformnya bisa setara dengan LLVM..
 
GN⁺ 2023-07-01
Komentar Hacker News

  • Andrew adalah sosok yang sangat tajam, jadi kalau itu sudah dinyatakan sebagai target, rasanya tim pada akhirnya akan berhasil mewujudkannya
    Namun, dari sudut pandang orang yang tidak terlalu paham kesulitan Zig terkait LLVM, keputusan ini terlihat seperti mengalihkan kapasitas tim ke alat pendukung seperti binutils alih-alih ke Zig itu sendiri
    Saat hanya melihat judulnya, saya kira mereka akan membuang kompilernya, dan untuk proyek seperti Zig, tampaknya ada banyak hal yang bisa diperoleh dengan tetap mempertahankan LLVM
    Meski begitu, gagasan menulis ulang banyak kode di dalam LLVM ke Zig alih-alih C++ terdengar cukup keren dan ambisius. Bisa dibilang sama ambisiusnya dengan upaya Lattner saat membuat LLVM
    Namun, kode yang tanpa sengaja menjadi kompleksitas waktu kuadratik juga akan sulit dihindari jika Zig nantinya menjadi sepopuler dan seberguna LLVM

    • Ini mengingatkan pada kalimat yang pernah saya baca dalam sebuah tulisan yang tampaknya merupakan dokumen manajemen proyek tidak resmi NASA
      Intinya, “jika sebuah misi antariksa tidak menggunakan kembali kendaraan peluncur yang sudah ada, maka proyek itu menjadi proyek pengembangan kendaraan peluncur, dan semua hal lain yang tadinya dianggap inti misi menjadi urusan sekunder”
      Bagian lain yang saya ingat menambahkan premis seperti, “alih-alih berkompromi agar sesuai dengan kendaraan peluncur yang ada, orang bisa saja berpikir akan lebih murah dan efisien membuat kendaraan peluncur yang cocok untuk misi tertentu”
    • Ini mengingatkan saya pada wawancara terbaru Chris Lattner tentang keberhasilan Swift. Menurutnya, salah satu faktor suksesnya adalah bisa mulai mencampurkan Swift ke proyek Objective-C besar tanpa harus menulis ulang apa pun
      Sebagian keberhasilan Rust juga bertumpu pada kompatibilitas serupa dengan C/C++
      Sulit membayangkan Zig bisa sukses tanpa kemampuan serupa, jadi saya berharap tonggak ini tidak didorong apa adanya
    • Ada perbedaan besar dengan LLVM. Setidaknya dalam konteks saat Apple mengambil alih proyek itu, pilihannya memang tidak banyak
      Karena GCC tidak mau mengizinkan atau mengimplementasikan hal-hal yang Apple inginkan atau butuhkan
    • Ini bukan berarti “sudah dinyatakan sebagai target”. Ini masih proposal yang belum diterima
    • binutils lebih mirip kumpulan kode serbaguna untuk menangani format kode biner secara portabel, dan kompilernya tidak memerlukan setengah dari itu, terutama untuk hal-hal legacy
      Jika lebih difokuskan seperti TCC, sebagian besar pekerjaannya akan jatuh ke sisi pembuatan kode untuk berbagai arsitektur

  • Ada dua masalah di sini. Yang satu adalah pembuatan kode dan yang lain adalah bootstrapping
    Dari pengalaman saya, pass optimisasi pada kompilator itu mudah ditulis dan menyenangkan. Untuk memahami alokasi register dan bentuk SSA memang perlu membaca paper, tetapi menulis kode yang mengalirkan IR melalui berbagai pass optimisasi sambil terus merapikannya bisa sangat menyenangkan
    Tanpa LLVM pun, pass optimisasi berkualitas tinggi masih bisa dibuat. Tetapi tahap melinierkan IR menjadi kode mesin adalah pekerjaan yang membosankan dan biasa saja, kecuali kalau Anda memang menyukai semua cara x86-32/64 mengenkode instruksi seperti “mov [eax+8*ebx], 123”
    Jika Anda mengoptimalkan ukuran biner, apakah Anda benar-benar ingin mengukur di platform mana “push eax; push eax; push eax” lebih pendek daripada “add rsp,12”? Itu baru cerita x86, dan kalau dikalikan dengan arsitektur non-x86 yang tidak penting bagi kebanyakan pengembang, skalanya jadi jauh lebih besar
    Sangat mungkin juga bug besar pada code generator untuk arsitektur yang jarang dipakai tidak ditemukan selama bertahun-tahun
    Yang kedua adalah bootstrapping. Kompilator Zig yang ditulis dalam Zig akan dikompilasi dengan apa? Misalnya, Anda bisa mengompilasi kompilator Zig dengan kompilator Zig minimal tanpa optimisasi yang ditulis dalam C
    Tetapi kalau tanpa optimisasi, Anda lalu harus mengompilasi ulang kompilator Zig dengan kompilator Zig yang sudah teroptimisasi. Bukan masalah yang tak terpecahkan, tetapi proses build yang panjang dan rumit berisiko mengusir calon kontributor

  • Zig sudah banyak dipromosikan karena bisa mengompilasi C, mungkin bahkan C++, jadi sekarang mengatakan akan sepenuhnya melepas LLVM terasa cukup ekstrem
    Kecuali jauh lebih banyak orang ikut mendukung, tampaknya sangat kecil kemungkinan mereka bisa mendekati tingkat dukungan platform milik LLVM
    Saya masih bisa memahami rencana menambahkan backend sendiri bagi yang menginginkannya, tetapi membuang LLVM begitu saja terasa terburu-buru

    • Kalau pekerjaannya sudah dimulai, mungkin itu bisa dibilang terburu-buru, tetapi seperti proposal lain tanpa label “accepted” di issue tracker, saat ini ini baru tahap meminta diskusi dan usulan tandingan
      Sekarang justru lebih dekat ke kebalikan dari terburu-buru, karena tim sedang mengumpulkan masukan, mempelajari use case yang terdampak, dan mengukur kelayakannya
    • Kalau membaca isi issue yang ditautkan, ini bukan menghapus backend LLVM sepenuhnya. LLVM hanya dipisahkan dari biner utama, dan kalau LLVM terpasang di sistem, itu masih bisa dengan mudah dipakai sebagai backend
      Agak aneh juga harus membundel salinan LLVM berukuran 100MB+ yang bahkan tidak diperlukan untuk kasus umum, jadi ini cukup masuk akal. Sebagai developer, banyak yang mungkin memang sudah memasangnya
      Namun, bisa jadi sulit menjamin bahwa Zig yang terpasang akan bekerja dengan benar dengan versi LLVM di sistem. Kita lihat saja nanti
    • Zig tetap akan menghasilkan bitcode LLVM, hanya saja tidak lagi bergantung pada library LLVM
      https://github.com/ziglang/zig/issues/13265
    • Saya juga menangkapnya persis seperti itu
      Belakangan ini saya membaca lebih banyak tentang Zig, dan juga sempat memakainya sebagai cara mudah mengompilasi C++ dengan LLVM tanpa harus bergulat dengan paket sistem. Fakta bahwa orang bisa berpindah dari C/C++ ke Zig adalah nilai jual yang besar
      Ini terasa sangat mendadak dan tidak terduga. Saya tidak tahu apakah ini tepat atau salah untuk proyeknya, tetapi dari sudut pandang saya, ini benar-benar terasa datang entah dari mana
    • Saya memakai Zig sebagai kompilator C++ di proyek Rust. Itu adalah cara yang paling tidak menyakitkan untuk melakukan cross-compilation di GitHub Actions

  • Di satu sisi, saya menghormati tekad teliti untuk mengurangi dependensi, tetapi harga yang harus dibayar tampak cukup serius
    Hilangnya kompatibilitas C++ pada dasarnya menghapus salah satu keunggulan yang paling sering disebut para penggemar Zig di sekitar saya
    Penurunan performa, meski mungkin hanya sementara, juga merupakan hal penting lain yang sering mereka sebutkan

    • Sebagian besar reaksi tampaknya menentang proposal ini
      Untuk orang yang hanya membaca sekilas, perlu ditekankan bahwa ini bukan keputusan final, melainkan sebuah proposal

  • Selama sekitar 4 tahun saya menulis seluruh proyek dan library embedded dengan Zig, jadi sekarang beberapa arsitektur dengan dukungan tier 1 akan hilang begitu saja?
    Bahasanya memang milik mereka, jadi terserah mau diapakan, tetapi kalau begitu saya harap branding-nya juga disesuaikan dengan itu

    • Apa benar akan hilang?
      Mungkin dukungan tier 1 akan terbagi menjadi dua kategori: dukungan tier 1 bawaan, dan dukungan tier 1 melalui backend LLVM opsional
      Jika suatu arsitektur sudah punya dukungan tier 1, tampaknya tidak ada alasan dukungan itu hilang hanya karena backend LLVM dijadikan dependensi opsional
      Seperti yang ditulis Andrew dalam proposalnya, pendekatan ini bahkan bisa menjadi jalan untuk mendukung arsitektur yang lebih jarang dengan lebih baik. Saya sendiri dengan senang hati akan mengerjakan backend Zig untuk arsitektur prosesor yang menarik, tetapi tidak akan pernah berkontribusi ke LLVM. Bekerja dengan C++ bukan sesuatu yang ingin saya lakukan sebagai hobi
    • Jadi maksudnya LLVM akan dibuang sambil semua hal yang dikerjakan LLVM diimplementasikan ulang dengan cara sendiri?
      Apa manfaatnya? Bukankah itu pemborosan sumber daya?
    • Bukan rahasia juga bahwa Zig masih sebelum 1.0. Sulit menyalahkan mereka sepenuhnya untuk hal ini, tetapi tetap saja ini tampak seperti proposal yang cukup ekstrem
    • Ini masih tahap proposal. Isu GitHub itu juga terutama untuk mengumpulkan use case pro dan kontra, dan statusnya bukan Accepted
    • Karena ini masih proposal, saya rasa kalau cukup banyak orang menyampaikan pendapat, seperti yang sudah banyak terjadi sekarang, tim inti juga akan menyesuaikan pendekatannya

  • DLang punya 3 compiler
    gdc berbasis backend GNU Compiler Collection, ldc berbasis backend LLVM, dan dmd berbasis generator kode x86 yang saya tulis untuk Zortech/Symantec/Digital Mars
    Masing-masing punya kelebihan, kekurangan, dan sasaran yang berbeda, tetapi bahasa D yang didukung tetap sama
    Secara umum para pengguna menyukai adanya pilihan, dan sebagian bahkan memakai lebih dari satu

    • Ada perbedaan pendekatan yang menarik. D tampaknya punya compiler yang benar-benar terpisah, sedangkan Zig kelihatannya bergerak ke arah compiler Zig utama yang mendukung LLVM sebagai backend jika itu terpasang
      Kalau memang begitu, saya suka pendekatan Zig
    • Bahasa lain yang juga punya banyak compiler adalah Common Lisp. Ada sekitar sepuluh compiler siap produksi, sebagian besar gratis meskipun ada juga yang komersial
      Ini sangat berguna karena saat pengembangan kita bisa memakai compiler tercepat, lalu untuk rilis final memakai compiler dengan runtime tercepat atau penggunaan memori paling kecil
      Selain itu, jika ada spesifikasi bahasa yang diikuti semua compiler, ada jaminan bahwa bahasanya stabil dan tidak tiba-tiba rusak dari bawah
      Tentu saja, ada juga kelebihan pada bahasa seperti Zig yang masih bisa mengubah apa yang diinginkan untuk membuat bahasanya lebih konsisten, rapi, dan kuat. Namun belakangan ini saya jauh lebih menghargai stabilitas semacam itu, karena saya bisa fokus memberi nilai nyata bagi pengguna alih-alih terus mengejar perubahan alat pengembangan
    • Adanya pilihan bagi pengguna tingkat lanjut memang kelebihan, tetapi harus memilih itu sendiri menurut saya adalah kekurangan besar
    • Saya paham pengguna menyukai pilihan, tetapi jika Zig menargetkan adopsi luas dalam jangka panjang, saya rasa DLang bukan preseden yang baik

  • Salah satu alasan utama Zig menarik bagi saya adalah karena bisa langsung disisipkan sebagai alternatif compiler C/C++
    Di Windows, teman-teman saya bilang Zig lebih mudah dipasang sebagai compiler C/C++ daripada alternatif lain mana pun
    Jika proposal ini diterima, secara pribadi saya rasa popularitas Zig akan turun sampai setara dengan Hare atau bahasa lain yang sangat niche
    Untuk membuat rekan kerja saya mau mencoba Zig sekali saja, saya bahkan harus mengirimkan tulisan bahwa Uber memakainya di produksi. Kalau tidak memberi nilai langsung pada proyek yang sudah ada, mereka tidak akan berpikir dua kali
    Meski begitu, saya paham latar belakang proposal ini. Waktu kompilasi LLVM bisa terasa mengerikan, dan punya bytecode sendiri memungkinkan teknik optimasi yang keren juga. Menangani bug LLVM pada praktiknya nyaris mustahil disentuh, dan saya juga melihat hal seperti itu di ekosistem Julia
    Kalau rekomendasi saya ada artinya, menurut saya Zig sebaiknya 1) memakai bytecode kustom untuk build debug demi build cepat dan debugging cepat, dan 2) memakai LLVM untuk build rilis demi performa runtime yang cepat
    Jika 1) bisa dilakukan sambil mempertahankan dukungan cross-compilation C/C++, misalnya dengan hanya menyerahkan bagian itu ke LLVM, maka meskipun ada trade-off harus memelihara kode backend tambahan, itu mungkin kompromi terbaik

    • Sebagai salah satu orang yang menangani bug LLVM di ekosistem Julia, ya, benar
      Itu membutuhkan keterampilan tersendiri yang berbeda dari kerja compiler Julia tingkat tinggi, dan kadang perlu waktu lama untuk menggabungkan perbaikan bug ke upstream
      Namun pada kenyataannya kami punya hubungan yang cukup baik dan produktif dengan upstream, dan jika kami memutuskan menghapus LLVM, proyek ini akan menyelesaikan jauh lebih sedikit hal
      Terutama dukungan GPU dan dukungan HPC, misalnya PPC, bergantung pada LLVM
      Karena itu kami tetap pada posisi bahwa Julia harus dibangun sesuai patchset/fork kami, dan kami tidak menginvestasikan waktu pada bug yang muncul pada build Julia tanpa patch tersebut. Ini khususnya sering terjadi pada build distribusi

  • Dari sudut pandang orang yang mengamati pengerjaan backend non-LLVM di bahasa lain, proposal yang ditautkan terasa terlalu penuh kesombongan
    Kalau penulisnya bukan orang itu, saya akan menganggapnya sebagai isu GitHub yang asal ditulis oleh pemula Zig
    Proposal itu meremehkan jumlah pekerjaan yang dibutuhkan, secara tersirat mengecilkan semua kerja yang sudah masuk ke LLVM, dan di setiap kalimatnya terasa kepercayaan diri sekaligus macho bahwa “jelas kita bisa membuatnya lebih murah, lebih cepat, dan lebih baik”. Mengecewakan
    Sampai sekarang saya benar-benar menghormati pekerjaan Andrew, jadi dengan niat baik saya ingin menganggap mungkin ini ditulis terburu-buru atau spontan sehingga terkesan seperti itu
    Namun tulisan ini tidak memberi kepercayaan, juga tidak membuat saya melihat proposalnya dengan pikiran yang lebih terbuka

    • Saya sama sekali tidak paham backend LLVM, tetapi library yang mencoba menyelesaikan 100% masalah pengguna pada akhirnya sering menjadi lebih sulit ditangani dan lebih lambat dibanding alternatif yang lebih teroptimasi
      Webpack dan esbuild adalah contohnya

  • Waktu yang tepat untuk membangun sesuatu tanpa LLVM adalah beberapa tahun lalu. Tetapi sekarang, kalau fitur C++ dihapus, itu kemungkinan akan menjadi akhir bagi Zig
    Mengejutkan bahwa alih-alih menghapusnya secara bertahap, mereka tidak mengumumkan rencana untuk menulis compiler C++ mereka sendiri dengan Zig

    • Menulis parser C++ saja sudah proyek yang sangat besar
      Saya bahkan tidak yakin seseorang yang memulainya pada ulang tahunnya yang ke-18 bisa menulis compiler C++. Mungkin sisa waktu hidupnya pun belum tentu cukup untuk membuat compiler yang benar-benar berfungsi

  • Zig ingin menjadi C baru bagi dunia, bukan terlalu ingin menjadi C++ baru bagi dunia
    Dari usulan ini juga terlihat bahwa cross-compile C akan tetap didukung
    Pilihan ini mungkin memang tepat. Saat ini C banyak digunakan di dunia embedded, dan di ranah itu LLVM kurang baik
    Kalau aku jadi Zig, aku juga ingin menargetkan semua mikrokontroler, dan ini satu-satunya jalan yang realistis untuk mencapainya