Backend x86 self-hosted kini ditetapkan sebagai default di mode debug

 (ziglang.org)
1 poin oleh GN⁺ 2025-06-09 | 1 komentar | Bagikan ke WhatsApp
  • Untuk target x86_64, Zig mengubah jalur default dari LLVM yang menurunkan bitcode menjadi file objek ke backend x86 self-hosted, sehingga kecepatan kompilasi build debug meningkat besar dan penggunaan memori turun signifikan
  • Backend x86 self-hosted lulus 1.987 behavior test, lebih banyak daripada 1.980 milik backend LLVM, dan sebagian pengujian tambahan dari total 2.084 hanya dijalankan pada pengujian x86 self-hosted
  • Pada benchmark hello.zig, rata-rata 918ms di jalur LLVM turun menjadi 275ms pada backend self-hosted default, sehingga wall time berkurang 70,1%, dan peak RSS juga turun dari 214MB menjadi 137MB
  • Bahkan pada proyek besar seperti compiler Zig sendiri, waktu build turun dari 75 detik menjadi 20 detik, tetapi Windows belum menjadi target pergantian default karena pekerjaan pada COFF linker masih diperlukan
  • Pekerjaan berikutnya mencakup paralelisasi penuh code generation, peningkatan linker, stabilisasi incremental compilation, peningkatan kualitas kode x86, dan perluasan backend aarch64

Peralihan backend default x86_64

  • Untuk build target x86_64, Zig kini secara default menggunakan backend x86 self-hosted
  • Jalur default sebelumnya adalah metode LLVM yang menurunkan file bitcode menjadi file objek
  • Di Windows, default ini belum diubah
    • Karena masih diperlukan lebih banyak pekerjaan pada COFF linker

Status kelulusan behavior test

  • Backend x86 self-hosted lulus 1.987 behavior test
  • Backend LLVM lulus 1.980 behavior test
  • Total behavior test ada 2.084, tetapi pengujian tambahan sebagian besar tumpang tindih dengan pengujian backend x86 milik LLVM sendiri
    • Pengujian tambahan ini hanya dijalankan saat pengujian x86 self-hosted
  • Berdasarkan jumlah kelulusan, backend x86 Zig kini lebih maju daripada backend LLVM dalam implementasi bahasa Zig

Mengapa bersaing dengan jalur LLVM

  • Alasan terbesar Zig bersaing dengan LLVM dalam code generation adalah karena hal ini bisa menciptakan perbedaan besar pada kecepatan kompilasi
  • Latar belakang terkait dirangkum dalam penjelasan di Ziggit

Benchmark hello.zig

  • Hasil zig build-exe hello.zig -fllvm:
    • Rata-rata wall time: 918ms
    • Peak RSS: 214MB
    • CPU cycles: 4.53G
    • Instructions: 8.50G
  • Hasil jalur default zig build-exe hello.zig:
    • Rata-rata wall time: 275ms
    • Peak RSS: 137MB
    • CPU cycles: 1.57G
    • Instructions: 3.21G
  • Backend self-hosted default menurunkan berbagai metrik dibanding jalur LLVM
    • Wall time turun 70,1%
    • Peak RSS turun 36,2%
    • CPU cycles turun 65,2%
    • Instructions turun 62,2%
    • Cache misses turun 86,1%
    • Branch misses turun 78,3%

Dampak pada proyek besar

  • Pada proyek yang lebih besar seperti compiler Zig sendiri, waktu build turun dari 75 detik menjadi 20 detik
  • Backend x86 self-hosted dapat memangkas waktu kompilasi secara besar bukan hanya pada contoh kecil, tetapi juga pada codebase besar

Pekerjaan berikutnya

  • Zig sudah memulai pekerjaan paralelisasi penuh code generation
  • Setelah peningkatan linker dan perbaikan bug lebih lanjut, incremental compilation dapat dibuat stabil dan kokoh bersama backend ini
  • Kualitas kode x86 yang dihasilkan masih menyisakan ruang untuk perbaikan
  • Target berikutnya adalah aarch64, dan pekerjaan diperkirakan akan dipercepat berkat pass Legalize yang baru
  • Build master branch terbaru bisa diunduh dari halaman unduhan Zig untuk dicoba langsung

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-09
Komentar Hacker News

  • Setahu saya Zig punya banyak pekerjaan yang sedang berlangsung untuk menghadirkan pengalaman pengembangan yang lebih baik. Hampir setiap hari ada sesuatu yang dikerjakan, dan barusan juga ada hal seperti https://github.com/ziglang/zig/pull/24124
    Dulu setahu saya hot code swapping juga pernah direncanakan, dan dengan kecepatan pengembangan saat ini saya tidak akan kaget kalau itu berjalan di x86_64 dalam waktu kurang dari setahun
    Rasa sakit terbesar saya saat ini secara pribadi adalah kecepatan comptime. Kompiler punya banyak pekerjaan yang harus dilakukan di sana, dan menjalankan DSL brainF** saat waktu kompilasi itu cukup lambat. Saya pernah mencobanya sendiri, dan itu eksperimen yang lucu
    Backend baru yang sedang diadopsi Zig secara keseluruhan sangat menarik. Saya ingin mencoba membuat sendiri backend URCL(https://github.com/ModPunchtree/URCL) untuk Zig

    • Soal peningkatan performa comptime, kami tahu apa yang perlu dilakukan, dan pekerjaan branch untuk itu juga sudah dimulai sejak lama. Hanya saja, karena perlu banyak mengerjakan ulang kode analisis semantik, ini jelas sesuatu yang bisa, harus, dan akan kami lakukan, tetapi sedang bersaing dengan prioritas lain
    • Hot code swapping akan sangat besar dampaknya untuk pengembangan game. Gagasan bahwa Zig pada dasarnya akan memberi dukungan bawaan hanya dengan satu flag kompiler itu luar biasa. Saya ingin bilang, coba lakukan itu dengan clang
    • Saya penasaran apakah lambatnya comptime benar-benar masalah besar. Saya sedang membuat pustaka JSON-RPC, dan sangat bergantung pada comptime untuk mendispatch permintaan JSON ke fungsi arbitrer
      Karena tipe statis yang ketat, tidak ada cara untuk melakukan dispatch dinamis saat runtime ke fungsi dengan parameter arbitrer, dan satu-satunya cara yang saya temukan adalah memetakan tipe fungsi saat waktu kompilasi dengan comptime
      Karena salinan kode hasil comptime bertambah untuk tiap fungsi arbitrer, sepertinya ukuran kode akan membesar
    • Saya penasaran apakah mudah membuat backend kustom. Saya belum melihatnya, tetapi ingin bereksperimen
      Secara spesifik, sepertinya mungkin membuat backend yang menerima AIR lalu menghasilkan laporan keamanan memori. Misalnya mengidentifikasi penggunaan nilai yang belum terdefinisi, stack pointer escape, use-after-free, double free, hal seperti alias xor mut, dan semacamnya
    • Saya sedang masuk ke lubang kelinci karena URCL. Saya belum mendalaminya, tetapi timeline yang paling lucu adalah ketika representasi perantara yang dibuat untuk Minecraft malah menjadi target kompilasi praktis untuk berbagai bahasa

  • Ini saja sudah pencapaian yang luar biasa, dan seperti yang tertulis di log pengembangan, masih banyak lagi yang akan datang. Ide tentang kompiler yang selama proses kompilasi hanya memodifikasi bagian yang diperlukan dari biner terasa segar sekaligus benar-benar radikal, dan sekarang tampaknya sudah masuk dalam jangkauan proyek Zig
    Saya menantikan kelanjutannya

  • Bagian “proyek besar seperti kompiler Zig turun dari 75 detik menjadi 20 detik. Ini baru permulaan” terasa sangat menjanjikan. Saya penasaran apa yang bisa dilakukan orang ini dengan itu, dan dia tampak benar-benar cerdas
    Saya penasaran bagaimana keadaan manajemen paket. Saya sempat mencoba membuat aplikasi QuickJS + SDL3, tetapi beralih ke Rust karena kekacauan di sisi C++, dan di sana semuanya berjalan begitu saja. Akan bagus kalau bisa juga mencobanya di Zig

    • Manajemen paket Zig lebih manual dibanding Rust. Caranya dengan mengambil URL paket lewat CLI lalu mengimpor modulnya dari skrip build
      Ini juga punya kelebihan, karena Anda bisa bergantung pada arsip arbitrer, dan banyak paket Zig yang membungkus pustaka C sebenarnya lebih mirip skrip build yang bergantung pada rilis tarball tanpa modifikasi. Tentu saja, ini sedikit lebih menantang bagi pemula
      Ada wrapper Zig native untuk SDL3: https://github.com/Gota7/zig-sdl3
      Ada juga yang lebih berupa repackaging dasar dari pustaka/API C: https://github.com/castholm/SDL
      Untuk QuickJS, satu-satunya pilihan adalah API C: https://github.com/allyourcodebase/quickjs-ng
      Zig membuat penggunaan paket C secara langsung dengan cara seperti ini menjadi sangat mudah, tetapi tipe Zig jauh lebih ketat sehingga saat berinteraksi dengan API Anda akan sering melakukan casting
    • Kompiler D dmd bisa mengompilasi dirinya sendiri dalam build debug
      real 0m18.444s, user 0m17.408s, sys 0m1.688s
      Bahkan pada prosesor yang sangat tua pun hasilnya segini, jadi saya tidak merasa perlu upgrade karena sudah terlalu cepat
      Spesifikasinya seperti AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2 core, 2.3GHz, cache 512KB
    • Saya penasaran apakah ada panduan untuk melakukannya. Saat saya pernah mengompilasi Zig, itu memakan waktu lama karena harus melewati beberapa tahap, termasuk seluruh proses bootstrap dari wasm
    • Menakjubkan bahwa Zig bisa mengompilasi dirinya sendiri dalam 75 detik. Bahkan kalau memakai LLVM pun begitu

  • Saya sudah mengatakan ini saat D dan Nature, tetapi untuk semua bahasa yang punya backend sendiri, kita punya kewajiban untuk mendukung proyek yang berusaha tidak bergantung pada LLVM
    Karena LLVM, riset dan pengembangan kompiler jadi mandek, terlalu banyak bahasa memutuskan bergantung pada LLVM, dan terlalu banyak orang tampaknya tidak lagi menganggap waktu iterasi cepat itu berharga atau berhenti berharap ada yang lebih baik
    Iterasi cepat lewat kompilasi inkremental dan patch biner, plus debugging yang bagus, seharusnya menjadi ekspektasi untuk bahasa baru, bukan dianggap fitur niche atau sesuatu yang terlalu sulit

    • Di sisi lain, LLVM juga membuat bahasa buatan individu langsung punya performa yang kompetitif dan dukungan platform yang luas, sehingga jumlahnya meledak. Zig juga salah satunya
      Seluruh industri rendering real-time pada dasarnya dibangun di atas LLVM atau fork LLVM, Microsoft juga mengganti kompiler shader-nya ke LLVM dan baru sekarang mulai meng-upstream kodenya
      Sebagian besar infrastruktur kompiler konsol game juga berbasis Clang. Xbox sampai sekarang masih bertahan dengan MSVC, tetapi itu nyaris pengecualian
      Secara keseluruhan, LLVM sangat sukses terutama dalam bootstrap hal-hal baru
    • Benar. Salah satu dari sedikit hal yang saya pandang positif dari Go adalah bahwa ia sudah bootstrap dan tidak bergantung pada LLVM

  • Tidak bermaksud terdengar seperti menuntut atau tidak berterima kasih. Zig dikerjakan secara gratis. Hanya saja, yang paling membuat penasaran adalah jadwal 1.0 yang realistis
    Zig hampir persis sesuai dengan yang saya inginkan dari bahasa tingkat rendah, dan saya sedang menunggu sampai stabil
    Tentu saja, saya sangat menghargai filosofi desain Zig yang minimalis

    • Proyek serius seperti TigerBeetle biasanya mengunci versinya, jadi kemungkinan memakai rilis terbaru. Saya melihat nightly lebih dekat ke ranah eksperimental

  • Program hello world yang dibuat dengan zig init berukuran 9.3MB saat dikompilasi. Dibandingkan dengan 7.6KB dari -Doptimize=ReleaseSmall, ini lebih dari 1000 kali lebih besar, sangat ekstrem

    • Itu pengamatan yang benar. Pengamatan lain adalah 82% dari ukuran itu adalah informasi debug
      -OReleaseSmall -fno-strip menghasilkan executable 580KB, dan -ODebug -fstrip menghasilkan executable 1.4MB
      Backend x86 Zig memberikan pengalaman debugging yang jauh lebih baik bersama fork lldb yang memahami Zig: https://github.com/ziglang/zig/wiki/LLDB-for-Zig
      Saya tidak ingat apakah saat ini logika comptime bisa di-step-through. Itu topik yang dibahas baru-baru ini

  • Sepertinya Julia perlu mempertimbangkan beralih ke Zig kalau ingin mendapat peningkatan performa yang berarti. Saya ingat para pengembang Julia cemas soal penurunan performa setiap kali ada rilis LLVM

    • Julia pada dasarnya sangat terikat ke LLVM. Sebagian besar ekosistemnya bergantung pada keberadaan LLVM karena intrinsic, diferensiasi otomatis (Enzyme), dan kompilasi GPU. Belum lagi Base dan Core
      Kompilernya cukup bisa ditargetkan ulang, dan ini juga area yang sedang aktif dikerjakan. Jadi di masa depan, mungkin saja Zig bisa dibayangkan sebagai kompiler alternatif untuk beberapa bagian bahasa
    • Bukankah LLVM dianggap sebagai bagian dari API publik Julia? Ada makro seperti @code_llvm yang benar-benar menampilkan IR
    • Ini mungkin bisa menjadi cara untuk mengurangi waktu kompilasi, tetapi menurut saya masih banyak pekerjaan yang harus dilakukan di sisi Julia
      Seperti cache kompilasi yang lebih granular, alat yang lebih baik untuk mencegah invalidasi, menghapus optimisasi world splitting, memperluas pemanfaatan multithreading di kompiler, prakompilasi otomatis untuk signature konkret, dan pembuatan kode yang lebih malas agar kode bisa di-hot-swap saat sudah terkompilasi
    • Setiap kali ada backend kompiler baru, komentar seperti ini selalu muncul. Saya cukup skeptis, tetapi akan menarik melihat apa yang terjadi kalau ada yang benar-benar menjadikannya proyek

  • Dari sudut pandang pemula total, saya penasaran apa yang membuat Zig lebih baik daripada bahasa lain. Saya memahaminya sebagai C yang lebih modern, tetapi apa sebenarnya bagian modern itu?

    • Beberapa hal yang langsung terpikir, ada sistem build terpadu yang tidak memakai banyak alat dan bahasa terpisah yang sulit dipahami
      Tidak seperti array di C, Zig punya slice yang mengetahui panjangnya sehingga lebih baik terkait buffer overflow, tipe optional eksplisit yang wajib diperiksa, dan pointer null tidak diizinkan. Bahkan saat diizinkan untuk integrasi dengan kode C, tipenya tetap secara jelas menunjukkan hal itu
      Ada juga enum, tagged union, dan pemeriksaan kelengkapan yang dipaksakan pada ekspresi switch
      Penanganan error bersifat eksplisit, dan fungsi mengembalikan error (nilai enum) yang harus ditangani pemanggil dengan satu cara atau lainnya. Di C, fungsi bisa mengembalikan integer yang menandakan error dan itu bisa diabaikan sepenuhnya
      Namun, belum ada cara standar yang tertanam di bahasa untuk mengembalikan data sekaligus error. Pola mengoper struct error lewat parameter terasa seperti tempelan, jadi menurut saya semestinya ada sintaks khusus untuk itu
      Ada blok defer dan errdefer untuk pembersihan setelah fungsi mengembalikan hasil atau saat error terjadi, dan alih-alih makro, Anda bisa memakai pembuatan kode comptime serta refleksi tipe seperti @typeInfo
      Anda meneruskan allocator ke library sehingga pemanggil biasanya menentukan di mana dan bagaimana memori dialokasikan, dan bahkan hanya dengan GeneralPurposeAllocator saja, kebocoran memori mudah ditemukan
      Setelah terus memakai bahasa tingkat tinggi sejak mulai belajar pemrograman, saya selalu membenci bagian-bagian C dan ekosistem sekitarnya yang sulit dipahami dan berlawanan dengan intuisi, tetapi Zig membuat saya untuk pertama kalinya menikmati pemrograman sistem

  • Apakah ini hanya mengganti backend? Saya penasaran apakah semua pass analisis dan tipe masih tetap ada, atau apakah verifikasinya juga dikurangi
    Siklus kompilasi cepat memang membantu produktivitas, tetapi menurut saya itu hanya benar jika juga mencakup pengujian yang cepat
    Kalau begitu, bukankah lebih mudah jika Zig untuk debug cukup dijalankan lewat interpretasi? Itu juga tampaknya akan menyelesaikan masalah harus mengulang pekerjaan untuk tiap target

    • Inti dari mode debug adalah kemampuan untuk di-debug, dan menjalankan Zig lewat interpretasi lalu menempelkannya ke debugger standar seperti gdb atau lldb tampaknya bukan hal sepele. Alat seperti itu mengharapkan executable dengan informasi debug DWARF
      Sebagai tambahan, di area seperti pengembangan game khususnya, performa mode debug juga benar-benar penting
    • Yang diganti hanyalah backend. Pengujian juga akan menjadi lebih cepat
      Tidak ada kebutuhan praktis untuk menambahkan interpreter. Adanya backend kustom berarti sekarang dipakai untuk debug, tetapi di masa depan yang jauh juga bisa bersaing dengan LLVM dalam hal kecepatan
      Menambahkan interpreter pun pada akhirnya tetap mengharuskan penulisan backend kustom, jadi kegunaannya kecil
      Masalahnya adalah LLVM lambat baik untuk debug maupun rilis

  • Bukankah ini salah satu prasyarat untuk menghadirkan kembali async/await ke Zig?
    https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-o...

    • Bagian itu sudah dibereskan, dan sepertinya dalam 2~3 bulan ke depan kami bisa membagikan pembaruan yang menarik. Kami sedang membangun ulang I/O dari dasar, dan sebagian besarnya adalah pekerjaan pustaka standar
    • Setelah membaca tautannya, async tampaknya tidak akan kembali, atau setidaknya tidak sebelum 2028