Sebuah backend kompiler baharu yang dipanggil TPDE-LLVM telah dibuka sumbernya, menjanjikan peningkatan dramatik dalam masa kompilasi sambil mengekalkan prestasi runtime yang serupa dengan backend standard -O0 LLVM. Projek ini menangani salah satu aduan yang paling berterusan mengenai LLVM: kelajuan kompilasi yang perlahan, terutamanya untuk build debug.
Peningkatan Kelajuan Yang Mengagumkan dengan Pertukaran
TPDE-LLVM menyampaikan kelajuan kompilasi yang 10-20 kali lebih pantas daripada backend -O0 LLVM merentasi pelbagai penanda aras. Ujian pada SPEC CPU 2017 menunjukkan peningkatan yang konsisten, dengan beberapa program seperti omnetpp dan xalanc menyaksikan kompilasi lebih 20x pantas. Walau bagaimanapun, kelajuan ini datang dengan kos saiz kod yang sedikit lebih besar, biasanya 10-30% lebih besar daripada output LLVM standard.
Komuniti telah menunjukkan reaksi bercampur terhadap keputusan ini. Walaupun sesetengah pembangun teruja dengan build debug yang lebih pantas, yang lain menunjukkan batasan penting. Backend ini pada masa ini hanya menyokong subset daripada perwakilan perantaraan (IR) LLVM dan menyasarkan hanya pemproses x86-64 dan AArch64.
IR (Intermediate Representation): Bahasa pengaturcaraan peringkat rendah yang digunakan secara dalaman oleh kompiler untuk mewakili kod sumber sebelum menukarkannya kepada kod mesin.
Keputusan Prestasi SPEC CPU 2017 (x86-64)
Benchmark | Peningkatan Kelajuan Kompilasi (-O0) | Nisbah Saiz Kod (-O0) | Peningkatan Kelajuan Kompilasi (-O1) | Nisbah Saiz Kod (-O1) |
---|---|---|---|---|
600.perl | 11.39x | 1.27x | 15.00x | 0.97x |
602.gcc | 12.54x | 1.32x | 17.55x | 1.01x |
605.mcf | 9.72x | 1.27x | 12.47x | 0.92x |
620.omnetpp | 21.46x | 1.24x | 26.49x | 1.03x |
623.xalanc | 18.99x | 1.24x | 24.80x | 0.98x |
625.x264 | 10.52x | 1.26x | 15.19x | 0.97x |
631.deepsjeng | 9.60x | 1.25x | 17.56x | 0.97x |
641.jeela | 21.44x | 1.24x | 18.36x | 0.95x |
657.x2 | 10.95x | 1.30x | 15.15x | 0.92x |
Min Geometri | 13.34x | 1.27x | 17.58x | 0.97x |
Inovasi Teknikal Di Sebalik Kelajuan
Rahsia kepada kelajuan TPDE-LLVM terletak pada pendekatan yang diperkemas. Daripada sistem pengoptimuman berbilang laluan yang kompleks LLVM, TPDE menggunakan hanya tiga laluan: pembersihan IR, analisis untuk gelung dan jangka hayat pembolehubah, dan penjanaan kod gabungan. Proses yang dipermudahkan ini mengendalikan penurunan, peruntukan daftar, dan penciptaan kod mesin sekaligus.
Perbincangan komuniti mendedahkan bahawa pendekatan ini berfungsi dengan baik untuk kod yang dijana kompiler biasa daripada Clang, dengan sokongan yang baik untuk Rust dan Flang juga. Walau bagaimanapun, beberapa perpustakaan Rust popular menggunakan jenis vektor khusus yang belum disokong, mengehadkan kegunaannya segera untuk semua projek.
Gambaran Keseluruhan Seni Bina TPDE-LLVM
- Reka Bentuk Tiga-Laluan: Pembersihan/penyediaan IR → Analisis (gelung + kelestarian) → Penjanaan kod gabungan
- Sasaran yang Disokong: x86-64 dan AArch64 sahaja
- Sokongan LLVM-IR: Subset biasa yang dijana oleh Clang -O0/-O1
- Pilihan Integrasi: Perpustakaan (kompilasi JIT), alat kendiri, integrasi Clang (memerlukan tampung)
- Had Semasa: Tiada sokongan DWARF, peruntukan daftar asas, platform ELF sahaja
Kesan Dunia Sebenar dan Batasan
Peningkatan prestasi terutamanya memberi manfaat kepada bahagian backend kompilasi. Dalam projek C/C++ biasa menggunakan Clang, frontend (menghurai kod sumber) mengambil 50-80% masa kompilasi. Dengan TPDE-LLVM, ini melonjak kepada lebih 98%, bermakna peningkatan keseluruhan kurang dramatik daripada yang dicadangkan oleh nombor backend.
Peningkatan 10-20x yang diterangkan di sini belum berfungsi untuk clang atau rustc, dan apabila ia berfungsi, ia hanya akan mempercepatkan bahagian backend. Namun begitu, ini masih merupakan kemenangan yang luar biasa untuk masa kompilasi kerana dua langkah lain boleh dioptimumkan secara berasingan.
Beberapa cabaran teknikal masih kekal. Sistem ini belum menyokong maklumat debug DWARF, menggunakan peruntukan daftar asas yang menumpahkan segala-galanya, dan tidak mempunyai sokongan untuk platform bukan-ELF. Para pembangun telah mengenal pasti ciri-ciri LLVM-IR khusus yang memperlahankan kompilasi, termasuk ungkapan malar dalam fungsi dan struktur data bersaiz sewenang-wenangnya.
Kesesakan Prestasi LLVM-IR yang Dikenal Pasti
Kesan Prestasi:
- ConstantExpr di dalam fungsi (memerlukan penulisan semula kepada arahan)
- Nilai struct/array bersaiz sewenang-wenangnya (kerumitan masa jalan kuadratik)
- PHINode::getIncomingValForBlock menyebabkan masa kompilasi kuadratik untuk blok dengan >1k pendahulu
Cabaran Pelaksanaan:
- Akses terus kepada global thread-local (memerlukan penjanaan panggilan fungsi)
- Aritmetik lebar bit sewenang-wenang (i268 dan lebar tidak standard yang serupa)
- Isu prestasi Live::successors memerlukan caching
Memandang Ke Hadapan
Projek ini mewakili langkah penting ke arah kompilasi yang lebih pantas, terutamanya berharga untuk aliran kerja pembangunan di mana iterasi pantas lebih penting daripada prestasi runtime yang optimum. Walaupun ia tidak akan menggantikan backend pengoptimuman LLVM untuk build keluaran, TPDE-LLVM boleh menjadi alat penting untuk pembangun yang menghabiskan masa yang ketara menunggu build debug untuk dikompil.
Keluaran sumber terbuka membenarkan komuniti yang lebih luas untuk bereksperimen dengan teknik-teknik ini dan berpotensi mengintegrasikannya ke dalam rantaian alat sedia ada. Sama ada ini membawa kepada penggunaan yang meluas atau mempengaruhi peningkatan dalam LLVM itu sendiri masih belum dapat dilihat, tetapi ia pastinya menunjukkan bahawa peningkatan kelajuan kompilasi yang dramatik adalah mungkin dengan pilihan seni bina yang betul.