compiler backend ตัวใหม่ที่เรียกว่า TPDE-LLVM ได้รับการเปิดตัวแบบ open source โดยสัญญาว่าจะเพิ่มความเร็วในการคอมไพล์อย่างมากในขณะที่ยังคงประสิทธิภาพ runtime ที่คล้ายคลึงกับ LLVM standard -O0 backend โปรเจกต์นี้แก้ไขปัญหาหนึ่งในข้อร้องเรียนที่ยืนยงที่สุดในการพัฒนาซอฟต์แวร์สมัยใหม่ คือเวลาการคอมไพล์ที่ช้าซึ่งส่งผลเสียต่อประสิทธิภาพของนักพัฒนา
การปรับปรุงความเร็วการคอมไพล์อย่างปฏิวัติ
TPDE-LLVM ให้ความเร็วในการคอมไพล์ที่เร็วกว่า LLVM -O0 backend ถึง 10-20 เท่าในการทดสอบต่างๆ จาก SPEC CPU 2017 suite ผลลัพธ์ที่น่าประทับใจที่สุดแสดงการเร่งความเร็วมากกว่า 26 เท่าสำหรับ workload บางตัวเช่น omnetpp และ xalanc นี่แสดงถึงความก้าวหน้าที่สำคัญในเทคโนโลยีการคอมไพล์ เนื่องจากแนวทางดั้งเดิมในการเร่งความเร็ว LLVM ให้ผลการปรับปรุงที่เล็กกว่ามาก
backend ดังกล่าวบรรลุผลลัพธ์เหล่านี้ผ่านแนวทางสามขั้นตอนที่เรียบง่าย: การทำความสะอาดและเตรียม IR การวิเคราะห์ loop และ variable liveness และขั้นตอนการสร้างโค้ดแบบรวมที่จัดการ lowering, register allocation และ machine code encoding พร้อมกัน การออกแบบนี้ขจัด overhead ส่วนใหญ่ที่มีอยู่ในสถาปัตยกรรม compiler แบบดั้งเดิม
IR (Intermediate Representation): ภาษาโปรแกรมระดับต่ำที่ใช้ภายใน compiler Register allocation: กระบวนการกำหนดตัวแปรของโปรแกรมให้กับ register ของโปรเซสเซอร์
ผลการทดสอบ SPEC CPU 2017 Benchmark (x86-64)
Benchmark | อัตราเร่งความเร็วการคอมไพล์ (-O0 IR) | อัตราส่วนขนาดโค้ด (-O0 IR) |
---|---|---|
600.perl | 11.39x | 1.27x |
602.gcc | 12.54x | 1.32x |
605.mcf | 9.72x | 1.27x |
620.omnetpp | 21.46x | 1.24x |
623.xalanc | 18.99x | 1.24x |
625.x264 | 10.52x | 1.26x |
631.deepsjeng | 9.60x | 1.25x |
641.leela | 21.44x | 1.24x |
657.xz | 10.95x | 1.30x |
ค่าเฉลี่ยเรขาคณิต | 13.34x | 1.27x |
การตอบสนองของชุมชนและศักยภาพการนำไปใช้
ชุมชน compiler แสดงความสนใจอย่างมากในแนวทางของ TPDE-LLVM โดยนักพัฒนาบางคนแสดงความประหลาดใจต่อการขาดการนำเทคนิคเหล่านี้ไปใช้อย่างแพร่หลาย เทคโนโลยีนี้ดูเหมือนจะมีข้อได้เปรียบที่ชัดเจนเหนือโซลูชันที่มีอยู่เช่น Cranelift และ WebAssembly backends ซึ่งนำไปสู่คำถามว่าทำไมโปรเจกต์ compiler หลักจึงไม่รีบรวมวิธีการที่คล้ายกันเข้าไป
พื้นที่หนึ่งที่น่าสนใจเป็นพิเศษคือการคอมไพล์ WebAssembly ซึ่งนักพัฒนากำลังพิจารณา TPDE-LLVM เป็นตัวเลือกทดแทนที่เป็นไปได้สำหรับโซลูชันการคอมไพล์เร็วที่มีอยู่ ความสามารถของ backend ในการทำงานเป็น library ทำให้เหมาะสมสำหรับสถานการณ์ just-in-time compilation เปิดโอกาสใหม่สำหรับการสร้างโค้ดแบบ runtime
ข้อจำกัดปัจจุบันและการพัฒนาในอนาคต
TPDE-LLVM ปัจจุบันรองรับเฉพาะสถาปัตยกรรม x86-64 และ AArch64 และใช้งานเฉพาะฟีเจอร์บางส่วนของ intermediate representation ของ LLVM นักพัฒนายอมรับว่าแม้ backend จะทำงานได้ดีกับโค้ด C และ C++ ทั่วไปที่สร้างโดย Clang แต่ก็มีข้อจำกัดกับฟีเจอร์ภาษาที่แปลกใหม่และโค้ด Rust บางส่วนที่ใช้ vector type ที่ไม่ใช่มาตรฐาน
แผนงานของโปรเจกต์รวมถึงการเพิ่มการรองรับการดีบักผ่านการใช้งาน DWARF format และการปรับปรุง register allocation เกินกว่าแนวทาง spill everything ปัจจุบัน แพลตฟอร์มเพิ่มเติมและ code model อาจได้รับการเพิ่มหากมีความต้องการจากชุมชนเพียงพอ
ข้อจำกัดปัจจุบันและฟีเจอร์ที่ยังไม่รองรับ
- การรองรับภาษา: ทำงานได้ดีกับโค้ด C/C++ ของ Clang ทั่วไป รองรับ Flang บางส่วน ความเข้ากันได้กับ Rust ยังจำกัด
- ฟีเจอร์ที่ขาดหายไป: ฟีเจอร์ LLVM-IR หลายอย่างยังไม่ได้นำมาใช้
- การดำเนินการเวกเตอร์: ไม่รองรับประเภทเวกเตอร์ที่ไม่ถูกต้อง (ส่งผลกระทบต่อ Rust crates บางตัว)
- การจัดสรรรีจิสเตอร์: ปัจจุบันใช้วิธี "spill everything"
- การดีบัก: การรองรับ DWARF อยู่ในขั้นตอนต้นแบบ
- ข้อจำกัดของแพลตฟอร์ม: รองรับเฉพาะ ELF และโมเดลโค้ด small-PIC เท่านั้น
ความท้าทายทางเทคนิคและการปรับปรุง LLVM
กระบวนการพัฒนาเผยให้เห็น performance bottleneck หลายจุดในโครงสร้างพื้นฐานของ LLVM ที่ส่งผลต่อความเร็วการคอมไพล์ ปัญหาเช่นการ iterate successor ที่ช้าสำหรับ switch statement และการดำเนินการแบบ quadratic-time สำหรับ block ที่มี predecessor จำนวนมากต้องการการแก้ไขแบบสร้างสรรค์ น่าสนใจที่ประมาณ 90% ของเวลาการคอมไพล์ในเครื่องมือของพวกเขาใช้ไปกับการ parse bitcode มากกว่าการสร้างโค้ดจริง
ทีม TPDE-LLVM ยังได้มีส่วนร่วมในการทำให้ LLVM มาตรฐานเร็วขึ้น โดยบรรลุการปรับปรุงความเร็ว 18% ในเวอร์ชันล่าสุด อย่างไรก็ตาม พวกเขาเชื่อว่าการบรรลุการเร่งความเร็วอย่างมากที่แสดงโดยแนวทางของพวกเขาจะต้องการการเปลี่ยนแปลงพื้นฐานในสถาปัตยกรรมของ LLVM ที่เกินกว่าการปรับปรุงแบบค่อยเป็นค่อยไป