Membandingkan Waktu Kompilasi Rust dan C++

Saya menemukan tulisan menarik di tempat lain dan ingin membagikannya.

Rust dan C++ sering menjadi bahan perbandingan dalam banyak hal. Namun, sulit untuk membandingkan waktu kompilasi secara langsung karena jarang ada proyek yang ditulis dalam kedua bahasa tersebut sekaligus. quick-lint-js disebut membandingkan waktu kompilasi dengan menulis ulang sebagian proyek yang semula ditulis dalam C++ ke Rust. Namun, Windows tidak disertakan dalam lingkungan kompilasinya.

Kriteria porting

• Tidak termasuk library pihak ketiga
• Dikerjakan di Linux dan macOS
• Test suite yang luas
• FFI, pointer, kontainer standar dan buatan sendiri, kelas dan fungsi utilitas, I/O, konkurensi, generik, makro, SIMD, pewarisan, ...

Kesimpulan

• Waktu kompilasi Rust mirip dengan atau lebih lambat daripada C++ (setidaknya pada proyek ini)
• Rust membutuhkan penulisan kode yang lebih banyak dibanding C++
• Pada build penuh (Full), C++ mirip atau lebih cepat
• Pada build inkremental (Incremental), kadang lebih singkat dan kadang lebih lama (bahkan bisa sangat lama)
• Diputuskan untuk tidak mem-porting sisa quick-lint-js ke Rust (mungkin akan dilakukan jika ada peningkatan waktu build?)

[freedomzero]

Sepertinya cukup banyak juga yang menggunakan Rust di dalam negeri. Saya penasaran kalian semua bekerja di industri apa.

[cr543l]

Setelah kompilasi pertama, kalau di C++ yang diubah adalah file .cpp tunggal, bukan file header h yang punya banyak dependensi, kompilasinya jadi sangat cepat. Jadi saya penasaran bagaimana dengan Rust.

[ssssss]

Sepertinya pembahasan terkait dijelaskan cukup rinci di bagian FAQ dokumentasi Rust, jadi saya bagikan di sini.

====================================
Kompilasi Rust terasa lambat. Mengapa begitu?

Karena Rust menerjemahkan kode ke bahasa mesin dan melakukan optimasi. Rust menyediakan abstraksi tingkat tinggi yang dikompilasi menjadi kode mesin yang efisien, dan proses penerjemahan ini memang memakan waktu, terutama saat optimasi diaktifkan.

Namun, waktu kompilasi Rust tidak seburuk yang dibayangkan, dan ada alasan untuk percaya bahwa ke depannya hal ini akan terus membaik. Jika membandingkan proyek dengan ukuran serupa di C++ dan Rust, waktu untuk mengompilasi seluruh proyek umumnya mirip. Alasan utama Rust terasa lambat adalah karena model kompilasi C++ dan Rust berbeda: unit kompilasi C++ adalah satu file, sedangkan Rust menggunakan crate yang terdiri dari beberapa file. Karena itu, saat satu file C++ diubah selama pengembangan, waktu kompilasinya bisa jauh lebih singkat dibanding Rust. Saat ini sedang berlangsung pekerjaan besar untuk merapikan compiler Rust agar mendukung incremental compilation, dan setelah selesai, waktu kompilasi Rust juga akan membaik seperti pada model C++.

Terlepas dari model kompilasi, desain bahasa Rust sendiri memiliki beberapa faktor yang memengaruhi waktu kompilasi.

Pertama, Rust memiliki sistem tipe yang relatif kompleks, dan perlu menghabiskan waktu kompilasi yang tidak sedikit untuk menegakkan berbagai batasan yang membuat Rust aman saat runtime.

Kedua, compiler Rust memiliki utang teknis lama, terutama karena kualitas LLVM IR yang dihasilkan kurang baik sehingga LLVM harus meluangkan waktu untuk “memperbaikinya”. Di masa depan, tahap optimasi dan translasi berbasis MIR mungkin dapat mengurangi beban yang diberikan compiler Rust kepada LLVM.

Ketiga, penggunaan LLVM oleh Rust untuk code generation adalah pedang bermata dua. Berkat LLVM, Rust mampu menunjukkan performa runtime kelas dunia, tetapi LLVM adalah framework besar yang tidak berfokus pada waktu kompilasi, dan sangat rentan terutama terhadap input berkualitas rendah.

Terakhir, strategi Rust yang melakukan monomorphisation pada tipe generik mirip seperti C++ memang menghasilkan kode yang cepat, tetapi masalahnya adalah strategi ini harus menghasilkan jauh lebih banyak kode dibanding strategi translasi lainnya. Pembengkakan kode ini dapat ditukar kelebihan dan kekurangannya dengan dynamic dispatch menggunakan trait object.

[bus710]

Yang pasti, saat build, proyek Rust memang sangat banyak memakan ruang disk. Saya ingat sempat kaget melihat proyek yang memakai sekitar seratus lebih library tiba-tiba memakai ruang sekitar 2GB...