Rust นำการสร้างโค้ดด้วย Cranelift มาใช้

 (lwn.net)
11 คะแนน โดย GN⁺ 2024-03-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cranelift เป็นแบ็กเอนด์สำหรับการสร้างโค้ดภายใต้ไลเซนส์ Apache-2.0 ซึ่งพัฒนาเป็นส่วนหนึ่งของรันไทม์ Wasmtime สำหรับ WebAssembly
  • ในเดือนตุลาคม 2023 โปรเจกต์ Rust เริ่มให้ Cranelift เป็นคอมโพเนนต์เสริมใน toolchain รุ่น nightly
  • ตอนนี้ผู้ใช้สามารถใช้ Cranelift เป็นแบ็กเอนด์สำหรับการสร้างโค้ดของ debug build ในโปรเจกต์ที่เขียนด้วย Rust ได้
  • Cranelift แข่งขันกับคอมไพเลอร์แบบเดิมด้วยการออกแบบที่เรียบง่ายกว่า โดยให้ความสำคัญเฉพาะการเพิ่มประสิทธิภาพที่สำคัญ จึงสร้างโค้ดได้เร็วกว่า

ความสำคัญของเวลาในการคอมไพล์

  • ผู้ใช้ภาษาโปรแกรมต้องการเวลาคอมไพล์ที่รวดเร็ว
  • Rust เช่นเดียวกับภาษาอื่นที่ใช้ LLVM เคยมีข้อร้องเรียนเกี่ยวกับเวลาในการคอมไพล์
  • คอมไพเลอร์ที่สร้างโค้ดได้เร็วเพียงพออาจได้เปรียบกว่าการใช้ interpreter
  • คอมไพเลอร์ที่เน้นความเร็วในการคอมไพล์อาจมีคุณค่าอย่างมาก

การเพิ่มประสิทธิภาพของ Cranelift

  • Cranelift ทำ optimization ระหว่างการสร้างโค้ดในหลายรูปแบบ
  • pipeline สำหรับ optimization อิงกับ E-graphs ซึ่งเป็นโครงสร้างข้อมูลที่ใช้แทนชุดของการแสดงผลระดับกลางได้อย่างมีประสิทธิภาพ
  • ในคอมไพเลอร์แบบดั้งเดิม ลำดับของ optimization ส่งผลอย่างมากต่อคุณภาพของโค้ดที่สร้างขึ้น
  • Cranelift ใช้ E-graph เพื่อไม่ให้ลำดับของ optimization ส่งผลต่อผลลัพธ์
  • การดึงการแสดงผลสุดท้ายออกจาก E-graph เป็นปัญหาแบบ NP-complete แต่ Cranelift ใช้ heuristic เพื่อดึงการแสดงผลที่ดีเพียงพอออกมาได้อย่างรวดเร็ว

Cranelift สำหรับ Rust

  • มีความพยายามอย่างมากในการใช้ Cranelift เป็นแบ็กเอนด์ของ Rust
  • คอมไพเลอร์ Rust ใช้ mid-level IR เพื่อแทนโปรแกรมที่ผ่านการตรวจสอบชนิดข้อมูลแล้ว
  • เพื่อใช้ Cranelift จึงจำเป็นต้องมีไลบรารีที่แปลง mid-level IR ไปเป็น CLIF
  • ไลบรารีนี้เขียนขึ้นเป็นหลักโดย "bjorn3" ซึ่งเป็นสมาชิกทีมคอมไพเลอร์ของ Rust
  • ผู้ใช้สามารถทดลองแบ็กเอนด์ Cranelift ได้ด้วย rustup และ cargo

ความเห็นของ GN⁺

  • การนำ Cranelift มาใช้สามารถมองได้ว่าเป็นการตอบสนองต่อความต้องการอย่างต่อเนื่องในชุมชน Rust ที่ต้องการลดเวลาในการคอมไพล์ ซึ่งอาจช่วยเพิ่มผลิตภาพของนักพัฒนา
  • แนวทางของ Cranelift ที่ใช้ E-graphs เพื่อแก้ปัญหาเรื่องลำดับของ optimization นำเสนอพาราไดม์ใหม่ในการออกแบบคอมไพเลอร์ และอาจชี้ทิศทางใหม่ให้กับการวิจัยและการพัฒนาคอมไพเลอร์
  • ในมุมมองเชิงวิพากษ์ ยังจำเป็นต้องพิสูจน์เพิ่มเติมผ่านกรณีใช้งานจริงว่า Cranelift มีความเสถียรและมีประสิทธิภาพเพียงใดเมื่อเทียบกับ LLVM
  • แบ็กเอนด์คอมไพเลอร์อื่นที่มีความสามารถคล้ายกับ Cranelift ได้แก่ libgccjit ของ GCC และการเปรียบเทียบกับทางเลือกเหล่านี้อาจช่วยให้เห็นข้อดีข้อเสียของ Cranelift ได้ชัดเจนขึ้น
  • นักพัฒนาที่จะนำ Cranelift มาใช้ควรพิจารณาความเข้ากันได้กับโครงสร้างพื้นฐานเดิมที่อิงกับ LLVM และต้นทุนในการย้าย พร้อมประเมินประสิทธิภาพและความเสถียรของ Cranelift อย่างรอบคอบ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-19
ความคิดเห็นบน Hacker News
  • สามารถใช้แบ็กเอนด์และการเพิ่มประสิทธิภาพต่างกันไปตามแต่ละ crate ได้ สำหรับ dependency การใช้ LLVM build ที่ปรับแต่งประสิทธิภาพแล้ว และใช้ debug LLVM หรือ Cranelift กับโค้ดของตัวเอง มักเป็นทางเลือกที่สมเหตุสมผล
  • บทความนี้ให้ภาพรวมที่ยอดเยี่ยมเกี่ยวกับความเร็วในการ optimize เทียบกับคุณภาพของการ optimize โดยเฉพาะอย่างยิ่ง copy-and-patch compilation ที่ใช้โค้ดคอมไพล์ล่วงหน้ายังคงเร็วที่สุด แต่มีพื้นที่ให้ optimize ได้น้อยกว่า Cranelift ใช้ e-graphs เพื่อแสดงความเท่าเทียมกันใน IR ทำให้สามารถ optimize ได้มากกว่าวิธี copy-and-patch ผลลัพธ์ที่ optimize สูงสุดน่าจะยังมาจาก toolchain คอมไพเลอร์แบบดั้งเดิมอย่าง LLVM หรือ GCC แต่สำหรับผู้ใช้ที่ต้องการผลลัพธ์ที่ "เร็วพอ" ให้ได้โดยเร็วที่สุด เทคโนโลยีคอมไพเลอร์แบบใหม่ก็มอบทางเลือกที่น่าสนใจ
  • มีคอมเมนต์จำนวนมากเกี่ยวกับ debug build ทั้งชุด แต่คิดว่าความแตกต่างที่สำคัญที่สุดคือเวลา incremental build สำหรับการเปลี่ยนแปลงเล็ก ๆ ซึ่งนี่แหละที่ช่วยเร่งรอบการพัฒนา เมื่อเปรียบเทียบเวลา build หลังแก้ไขเล็กน้อยในโปรเจ็กต์ rust-analyzer และ gleam การเพิ่ม Cranelift และ mold ให้ผลการปรับปรุงที่รวดเร็วกว่ามาก และเมื่อเทียบกับ Terraform ที่ build ด้วยภาษา Go ก็ยังแสดงให้เห็นการปรับปรุงครั้งใหญ่ของ Rust
  • ตอนนี้ยังไม่รองรับ Mac M1-M3 และดูเหมือนจะยังไม่รองรับ Windows ด้วย อัปเดตล่าสุดจากผู้มีส่วนร่วมที่เคลื่อนไหวมากที่สุดก็ยังสรุปได้ไม่ชัดเจน โดยตอนนี้เว้นการรองรับ Windows ไว้ก่อน และ macOS รองรับเฉพาะ x86_64 หากใช้โปรเซสเซอร์ M1 ก็อาจลองติดตั้ง rustc เวอร์ชัน x86_64 และใช้ Rosetta 2 ได้ แต่ Rosetta 2 อาจกระทบประสิทธิภาพ จึงควรลองเทียบกับแบ็กเอนด์ LLVM
  • ได้ลองทำตามคำแนะนำในบทความกับโปรเจ็กต์ Bevy และเปรียบเทียบกับ build แบบ "ปกติ" ดูเหมือน release build จะเร็วกว่าเมื่อเทียบกับ Cranelift+debug build แต่เป็นเพราะใช้ sccache และแคชบน NAS ภายใน เมื่อทดลองใหม่เฉพาะ debug build โดยไม่ใช้แคช เวลาคอมไพล์ลดลงเกือบครึ่ง
  • เจอ ESC/Java ผ่านลิงก์ Equality Graphs เลยสงสัยว่ามีใครเคยลองใช้ ESC/Java จริง ๆ หรือใช้งานจนประสบความสำเร็จบ้างไหม น่าสนใจที่จะเปรียบเทียบกับ Spot bugs (เดิมรู้จักกันในชื่อ Findbugs)
  • ตื่นเต้นมากที่ debug build ด้วย Cranelift จะช่วยให้รอบการพัฒนาเร็วขึ้น โดยเฉพาะ Rust ฝั่ง WASM/Frontend ที่ความเร็วในการวนรอบสำคัญมาก ยุคใหม่ของเครื่องมือ Rust บางครั้งให้ build ได้ในเวลาไม่ถึง 1 วินาที แต่ตอนนี้ยังไม่รองรับ ARM macOS ดังนั้นผู้ใช้ M1-3 คงต้องรออีกหน่อย
  • สงสัยว่ามี benchmark ด้าน runtime (ไม่ใช่เวลาคอมไพล์) ตอนใช้ Cranelift หรือไม่ ในบทความมีการพูดถึงว่า "ช้ากว่าสองเท่า" แต่ข้อมูลนั้นอ้างอิงจากปี 2020 จึงสงสัยว่าหลังจากนั้นมีการปรับปรุงไปมากแค่ไหน
  • สงสัยว่ามีใครอธิบายได้ไหมว่าทำไม Cranelift จึงถูกคาดว่าจะเร็วกว่า LLVM และเหตุใดการปรับปรุงเหล่านั้นจึงไม่สามารถนำไปใช้กับ LLVM ได้ด้วย