ความเร็วคอมไพล์ของ Rust ที่เร็วขึ้นด้วยฟรอนต์เอนด์แบบขนานในเวอร์ชัน nightly

 (blog.rust-lang.org)
2 คะแนน โดย GN⁺ 2023-11-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คอมไพล์ได้เร็วขึ้นด้วยฟรอนต์เอนด์แบบขนานของคอมไพเลอร์ Rust

  • ฟรอนต์เอนด์ของคอมไพเลอร์ Rust สามารถลดเวลาคอมไพล์ได้อย่างมากด้วยการทำงานแบบขนาน
  • ฟรอนต์เอนด์แบบขนานเป็นฟีเจอร์ทดลองที่สามารถลองใช้ได้ในคอมไพเลอร์ nightly ด้วยออปชัน -Z threads=8
  • มีแผนจะออกในคอมไพเลอร์รุ่นเสถียรภายในปี 2024

เวลาคอมไพล์และความขนาน

  • เวลาคอมไพล์ของ Rust เป็นประเด็นที่ได้รับความสนใจมาอย่างต่อเนื่อง และคณะทำงานด้านประสิทธิภาพของคอมไพเลอร์ก็ได้ปรับปรุงประสิทธิภาพของคอมไพเลอร์อย่างต่อเนื่องมาหลายปี
  • ในช่วง 10 เดือนแรกของปี 2023 เวลาคอมไพล์ลดลงเฉลี่ย 13% การใช้หน่วยความจำลดลง 15% และขนาดไบนารีลดลง 7%
  • คอมไพเลอร์ถูกปรับแต่งมาอย่างมากแล้วจนยากที่จะหาจุดปรับปรุงใหม่ ๆ และความขนานยังคงเป็นโอกาสในการปรับปรุงที่มีผลมากแต่ทำได้ยาก

ความขนานระหว่างโปรเซสที่มีอยู่เดิม

  • เมื่อคอมไพล์โปรแกรม Rust, Cargo จะรันหลายโปรเซสของ rustc แบบขนานเพื่อคอมไพล์หลายเครต
  • การรันแบบขนานทำได้ดีเมื่อมีการพึ่งพาระหว่างเครตน้อย แต่ยิ่งมีการพึ่งพามาก ความขนานก็จะลดลง

ความขนานภายในโปรเซสที่มีอยู่เดิม: แบ็กเอนด์

  • คอมไพเลอร์แบ่งออกเป็นฟรอนต์เอนด์และแบ็กเอนด์ โดยแบ็กเอนด์รับผิดชอบการสร้างโค้ด และ LLVM จัดการส่วนนี้แบบขนานอยู่แล้ว
  • ฟรอนต์เอนด์ทำงานอย่างการพาร์สและการตรวจสอบชนิดข้อมูล แต่จนถึงสัปดาห์นี้ยังไม่สามารถทำงานแบบขนานได้

ความขนานภายในโปรเซสแบบใหม่: ฟรอนต์เอนด์

  • ตอนนี้ฟรอนต์เอนด์สามารถใช้ Rayon เพื่อทำงานคอมไพล์แบบขนานละเอียดระดับย่อยได้แล้ว
  • เมื่อเปิดใช้ฟรอนต์เอนด์แบบขนานและตั้งค่าให้ใช้ 8 เธรด จะเห็นได้ว่าเวลาทำงานของฟรอนต์เอนด์ลดลงอย่างมาก

การผสานภาพรวมทั้งหมด

  • การคอมไพล์ Rust ได้รับประโยชน์จากความขนานระหว่างโปรเซสผ่าน Cargo และความขนานภายในโปรเซสของแบ็กเอนด์มาเป็นเวลานาน และตอนนี้ก็สามารถได้รับประโยชน์จากความขนานภายในโปรเซสของฟรอนต์เอนด์ได้แล้ว
  • คอมไพเลอร์ใช้โปรโตคอล jobserver เพื่อจำกัดจำนวนเธรดที่สร้างขึ้นไม่ให้เกินจำนวนคอร์

วิธีใช้งาน

  • คอมไพเลอร์ nightly ถูกปล่อยออกมาโดยเปิดใช้ฟรอนต์เอนด์แบบขนานแล้ว แต่โดยค่าเริ่มต้นจะทำงานในโหมดเธรดเดียว
  • ผู้ใช้สามารถสลับไปใช้โหมดหลายเธรดได้ด้วยออปชัน -Z threads

ผลกระทบต่อประสิทธิภาพ

  • การรันฟรอนต์เอนด์แบบขนานในโหมดเธรดเดียวอาจทำให้เวลาคอมไพล์ช้าลง 0% ถึง 2% เมื่อเทียบกับเดิม
  • ในโหมดหลายเธรด เวลาคอมไพล์อาจลดลงได้สูงสุด 50% แต่ผลลัพธ์จะแตกต่างกันไปตามลักษณะของโค้ดและการตั้งค่าการบิลด์

ความถูกต้อง

  • ในโหมดเธรดเดียว คาดว่าจะมีความน่าเชื่อถือสูง
  • ในโหมดหลายเธรดอาจยังมีบั๊กที่ทราบอยู่แล้วและเดดล็อกได้ แต่ไบนารีที่คอมไพเลอร์สร้างขึ้นควรเหมือนกันไม่ว่าจะใช้ฟรอนต์เอนด์แบบใด

ฟีดแบ็ก

  • หากพบปัญหากับฟรอนต์เอนด์แบบขนาน สามารถตรวจสอบอิสชูที่มีป้ายกำกับ "WG-compiler-parallel" และส่งอิสชูใหม่ได้

งานในอนาคต

  • ขณะนี้กำลังมีการปรับปรุงประสิทธิภาพของฟรอนต์เอนด์แบบขนานและแก้ไขบั๊กในโหมดมัลติเธรด
  • มีแผนจะทำให้ออปชัน -Z threads เป็นฟีเจอร์เสถียร และให้รันในโหมดหลายเธรดโดยค่าเริ่มต้นในรุ่นเสถียรปี 2024

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

ประเด็นสำคัญที่สุดของบทความนี้คือ ฟรอนต์เอนด์ของคอมไพเลอร์ Rust รองรับการทำงานแบบขนานได้แล้ว ทำให้ลดเวลาคอมไพล์ลงได้อย่างมาก นี่เป็นข้อได้เปรียบสำคัญสำหรับนักพัฒนา Rust ในด้านความเร็วในการคอมไพล์ และจะช่วยสร้างสภาพแวดล้อมการพัฒนาที่มีประสิทธิภาพมากขึ้น การนำฟรอนต์เอนด์แบบขนานมาใช้ถือเป็นข่าวที่น่าตื่นเต้นสำหรับชุมชน Rust และมองได้ว่าเป็นผลลัพธ์ของความพยายามอย่างต่อเนื่องในการปรับปรุงประสิทธิภาพ

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

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

 
GN⁺ 2023-11-11
ความคิดเห็นจาก Hacker News
  • ความคาดหวังต่อการปรับปรุงความเร็วคอมไพล์ของ Rust
    • ความเร็วคอมไพล์ที่ช้าของ Rust มักถูกมองว่าเป็นข้อเสีย โดยเฉพาะเมื่อทำงานกับรีโพซิทอรีขนาดใหญ่ เพราะทำให้ต้นทุน CI/CD สูงขึ้นและทำให้เวลาพัฒนายืดออก ยิ่งเป็นปัญหาเมื่อจำเป็นต้องล้างแคช (ซึ่งบางครั้งเกิดจากบั๊กของ Docker) จึงมีเสียงตอบรับเชิงบวกต่อความคืบหน้านี้
  • ประสบการณ์ส่วนตัวเกี่ยวกับความเร็วคอมไพล์ของ Rust
    • เมื่อนานมาแล้วตอนที่เคยใช้ Rust ความเร็วคอมไพล์ค่อนข้างช้า แต่เมื่อกลับมาใช้อีกครั้งในช่วงหลัง แทบไม่ต้องกังวลเรื่องเวลาคอมไพล์เลย อย่างไรก็ตาม เมื่อโปรเจ็กต์ใหญ่ขึ้นก็ยังเริ่มรู้สึกถึงความหน่วงอยู่บ้าง จึงมองว่าการปรับปรุงนี้เป็นข่าวดีมากสำหรับตัวเอง
  • คำถามเกี่ยวกับกระบวนการคอมไพล์ของ Rust
    • มีคำถามว่า frontend ของ Rust จำเป็นต้องทำ borrow checking ให้เสร็จก่อนที่ backend จะเริ่มทำงานหรือไม่ และตั้งข้อสงสัยว่า หาก backend พบข้อผิดพลาดจาก borrow checking ก็อาจทิ้งงานที่ทำแบบคาดการณ์ไว้ได้หรือไม่
  • ข้อสังเกตเกี่ยวกับการคอมไพล์ binary crate ของ Rust
    • ต่างจาก library crate, binary crate มักมีขนาดใหญ่และมีโครงสร้างแบบก้อนเดียวโดยปริยาย ทำให้คอมไพล์แบบขนานได้ยาก และ crate ที่ใหญ่ที่สุดมักกลายเป็นคอขวดแบบลำดับเดียว จึงเป็นเรื่องน่ายินดีที่ปัญหานี้กำลังได้รับการปรับปรุง
  • คำถามเกี่ยวกับการใช้ CPU core
    • มีคำถามว่าสามารถตั้งให้ใช้จำนวน CPU core โดยอัตโนมัติระหว่างคอมไพล์ได้หรือไม่ หรือจำเป็นต้องใส่ค่าคงที่ไว้ในไฟล์ตั้งค่าที่ถูกใช้บนเครื่องอื่นด้วย
  • คำเตือนเกี่ยวกับบั๊กในโหมดมัลติเธรด
    • มีคำเตือนว่าโหมดมัลติเธรดมีบั๊กรู้จักกันอยู่และอาจเกิด deadlock ได้ ดังนั้นหากการคอมไพล์ค้าง ก็อาจเป็นไปได้ว่าเจอปัญหาเหล่านี้อย่างใดอย่างหนึ่ง จึงมีท่าทีระมัดระวังต่อการใช้ตัวเลือก -Z threads
  • การประเมินเชิงบวกต่อสถานะปัจจุบันของความเร็วคอมไพล์ Rust
    • หลังจากไม่ได้ใช้ Rust มาหลายปี พอกลับมาลองใช้อีกครั้งก็พบว่าความเร็วคอมไพล์แทบจะทันทีทันใด อีกทั้งด้วยเครื่องมืออย่าง ChatGPT ทำให้ปัญหา Rust ที่เมื่อก่อนแก้ได้ยาก กลายเป็นแก้ได้ง่ายขึ้นมาก ทำให้สถานะปัจจุบันถือว่าดีมาก
  • ข้อสงสัยเกี่ยวกับทิศทางของการเพิ่มประสิทธิภาพการคอมไพล์ Rust
    • มีความกังวลว่าในเมื่อการคอมไพล์ของ Rust ถูกทำให้ขนานกันได้สูงมากอยู่แล้วในระดับไฟล์ การเร่งความเร็วการคอมไพล์ไฟล์เดียวจะไปแย่งทรัพยากรจากการทำงานขนานในระดับที่สูงกว่าหรือไม่ และชี้ว่าปัญหาคือยังไม่มีข้อมูลเชิงตัวเลขที่ชัดเจนเกี่ยวกับเรื่องนี้
  • ความคิดเห็นที่ยินดีต่อการปรับปรุงความเร็วคอมไพล์ของ Rust