krabby: สร้างคอมไพเลอร์ Rust ที่เร็วขึ้น

 (bal-e.org)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Krabby คือการพัฒนาคอมไพเลอร์ Rust แบบเริ่มจากศูนย์ ที่ให้ความสำคัญกับประสิทธิภาพเป็นหลัก เพื่อแก้ปัญหาความเร็วในการคอมไพล์ที่ช้าของ rustc
  • การปรับปรุงประสิทธิภาพของ rustc ที่ผู้ใช้รู้สึกได้ในตอนนี้ ไม่ได้มาจากการแก้ฟังก์ชันเดี่ยวอีกต่อไป แต่เกิดจาก การเปลี่ยนแปลง API และโครงสร้างข้อมูล ทว่าในโค้ดเบสขนาดใหญ่และมีข้อกำหนดด้านเสถียรภาพสูง ทำให้การเปลี่ยนแปลงขนาดใหญ่ทำได้ยาก
  • Krabby พยายามออกแบบส่วนประกอบของคอมไพเลอร์ใหม่ไปพร้อมกันในโค้ดเบสขนาดเล็กที่คนคนเดียวควบคุมได้ โดยไม่ยึดเสถียรภาพเป็นลำดับแรก เพื่อค้นหา โอกาสในการปรับแต่งประสิทธิภาพ แบบใหม่และสถาปัตยกรรมที่มีความเป็นเอกภาพมากขึ้น
  • เป้าหมายคือการทดสอบสมมติฐานว่า หากต้องการยกระดับประสิทธิภาพของคอมไพเลอร์อย่างมาก จำเป็นต้องทบทวนการออกแบบใหม่ทั้งหมด แม้กระทั่งกับภาษาที่ซับซ้อนอย่าง Rust
  • โค้ดเปิดเผยอยู่ที่ ที่เก็บ krabby บน Codeberg และตั้งเป้าอัปเดตความคืบหน้าบน Fediverse อย่างน้อยทุก 1–2 สัปดาห์

เป้าหมายและที่มาของ Krabby

  • Rust เป็นภาษาที่ผู้เขียนชื่นชอบ แต่คอมไพเลอร์ rustc ช้าจนสังเกตได้ชัด
  • มีผู้คนจำนวนมากพยายามปรับปรุงประสิทธิภาพของ rustc อยู่แล้ว และการปรับปรุงที่ช่วยให้ผู้ใช้รู้สึกถึงความเร็วที่ดีขึ้นจากการแก้ฟังก์ชันเดี่ยว ๆ นั้น แทบจะถูกนำไปใช้หมดแล้ว
  • การปรับปรุงที่มีนัยสำคัญในตอนนี้จึงมาจาก การเปลี่ยนแปลง API และโครงสร้างข้อมูล แต่ในโค้ดเบสขนาดใหญ่อย่าง rustc การเปลี่ยนแปลงระดับใหญ่แทบเป็นไปไม่ได้จริง เพราะมีทั้งการพัฒนาฟีเจอร์หลายด้านและข้อกำหนดด้านเสถียรภาพ
  • Krabby คือ การพัฒนาคอมไพเลอร์ Rust แบบเริ่มจากศูนย์ ที่ให้ความสำคัญกับประสิทธิภาพเป็นหลัก และมีเป้าหมายต่างจาก rustc โดยพื้นฐาน
  • เพราะเป็นโค้ดเบสขนาดเล็กที่คนคนเดียวควบคุมได้ และไม่ได้ให้เสถียรภาพเป็นลำดับแรก จึงสามารถออกแบบทุกองค์ประกอบโดยพิจารณาความสัมพันธ์ร่วมกัน เพื่อค้นหาโอกาสใหม่ในการปรับแต่งประสิทธิภาพและสร้างสถาปัตยกรรมที่มีความสอดคล้องมากกว่าเดิม
  • โครงการนี้ตั้งต้นจากสมมติฐานว่า หากต้องการปรับปรุงประสิทธิภาพของคอมไพเลอร์อย่างมาก จำเป็นต้องคิดใหม่เกี่ยวกับการออกแบบคอมไพเลอร์ทั้งหมด
  • ผู้เขียนต้องการแสดงให้เห็นว่า การปรับแต่งสถาปัตยกรรมในระดับใหญ่ยังอาจซ่อนอยู่ได้ไม่ว่าภาษาเป้าหมายจะเป็นภาษาใด และแนวคิดนี้ใช้ได้ไม่เฉพาะกับภาษาง่าย ๆ อย่าง C แต่รวมถึงภาษาที่ซับซ้อนอย่าง Rust ด้วย
  • แม้สุดท้ายการออกแบบที่ได้จะเฉพาะทางสำหรับ Rust ผู้เขียนก็มองว่าความรู้ที่ได้จากกระบวนการนี้ยังมีคุณค่า

สถานะโครงการและข้อมูลที่เปิดเผย

  • Krabby เป็นโครงการที่ใหญ่มาก และผู้เขียนเองก็ยังไม่แน่ใจว่าจะทำสำเร็จได้หรือว่าตนเป็นคนที่เหมาะสมกับงานนี้หรือไม่
  • อย่างไรก็ดี ผู้เขียนชอบกระบวนการปรับโค้ดให้มีประสิทธิภาพสูงขึ้นและมีความสมบูรณ์มากขึ้น และความสนุกจากการเขียนโค้ดดี ๆ เพื่อเป้าหมายที่มองว่ามีคุณค่านี้เองคือแรงผลักดันมาจนถึงตอนนี้
  • โค้ดเปิดเผยอยู่ที่ ที่เก็บ krabby บน Codeberg
  • ตั้งเป้าอัปเดตความคืบหน้าบน Fediverse อย่างน้อยทุก 1–2 สัปดาห์ และจะโพสต์อัปเดตฉบับยาวที่ลงลึกกว่านี้บนเว็บไซต์เดียวกัน
  • ผู้ที่สนใจสามารถ ติดต่อทางอีเมล ได้

  • บทความความคืบหน้าที่เกี่ยวข้อง

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

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

 
GN⁺ 1 시간 전
ความเห็นจาก Lobste.rs

  • ดูเหมือนทุกคนจะอยากมี ใบอนุญาตอวดเท่ เป็นของตัวเอง https://codeberg.org/bal-e/krabby/…

    • ถ้าเป็นโปรเจกต์งานอดิเรกก็คงพอเข้าใจได้ แต่ก็เป็นสัญญาณว่าโปรเจกต์นี้เป็น โปรเจกต์สบาย ๆ มากกว่าจะจริงจัง
      ใบอนุญาตนี้ระบุว่าอนุญาตให้ใช้งานและแชร์ได้ฟรีสำหรับการใช้งานส่วนบุคคลและไม่ใช่เชิงพาณิชย์ แต่ซอฟต์แวร์ที่สร้างต่อยอดจากมันก็ต้องแชร์ภายใต้เงื่อนไขเดียวกัน และการใช้งานเชิงพาณิชย์ให้ทดลองใช้ได้เพียง 30 วัน
      สงสัยว่า Codeberg บังคับเงื่อนไข libre/โอเพนซอร์สกับไลเซนส์ของโปรเจกต์เข้มงวดแค่ไหน เพราะเข้าใจว่า Codeberg โฮสต์เฉพาะ FOSS เลยแปลกใจที่มี ข้อจำกัดการใช้งานแบบไม่ใช่เชิงพาณิชย์ แต่อาจเป็นเพราะผมตามสถานการณ์ล่าสุดไม่ทัน
    • ใช่ ผมก็ทราบเหมือนกัน... ผมคิดเรื่องไลเซนส์นี้มาค่อนข้างนานแล้ว และกำลังพิจารณาเปลี่ยนเป็น AGPL ในช่วงที่ยังทำคนเดียวอยู่

  • Rust มีขนาดใหญ่มาก โปรเจกต์นี้ดูเหมือนจะง่ายกว่าการ “สร้างเว็บเบราว์เซอร์ขึ้นมาเอง” อยู่นิดหน่อย แต่ก็ยังไม่ใช่ว่าง่ายเลย อย่างไรก็ดีขอชื่นชมที่ตั้งเป้าใหญ่
    จาก krabby: motivations ดูเหมือนว่าเหตุผลหลักของโปรเจกต์นี้คือเรื่องความเร็ว
    เท่าที่ผมเข้าใจ Rust การตรวจชนิด, borrow checking ฯลฯ เร็วมากอยู่แล้ว และคอขวดคือ การสร้างโค้ด ซึ่งส่วนใหญ่เกี่ยวกับ LLVM มากกว่าตัว Rust เอง
    สงสัยว่าช่วงนี้ฝั่ง Cranelift เป็นอย่างไรบ้าง และมีส่วนที่ทับซ้อนกับแนวคิดการเร่งความเร็วในการสร้างโค้ดหรือไม่

    • สมมุติฐานนั้นตั้งอยู่บนแนวคิดว่าโครงสร้างทั้งหมดของ rustc+LLVM นั้นถูกต้อง แล้วตอนนี้เหลือแค่เรื่อง ค่าคงที่ของปัจจัย เท่านั้นที่สำคัญ
      ส่วนตัวผมค่อนข้างมั่นใจว่าเมื่อมองทั้ง pipeline ของการคอมไพล์แล้ว มันฟังไม่ค่อยขึ้นนัก เราต้องการ rlib สำหรับ MIR โดยเฉพาะ และต้องการ backend ที่ทำ whole-world optimization ได้โดยไม่ต้องมี RAM แบบไม่จำกัด (คอมเมนต์นี้ ประกอบ)
      “Codegen Unit” เป็นความซับซ้อนที่เกิดขึ้นโดยบังเอิญล้วน ๆ
    • ขึ้นอยู่กับว่าคุณกำลังทำอะไรอยู่กันแน่: Depends on what exactly you're doing
      โดยเฉพาะการแยกรายละเอียดของ libraries และ binaries อาจน่าสนใจ
      LLVM ไม่ได้เร็วมากนักอยู่แล้ว แต่ถ้าจำไม่ผิด rustc เองก็มีแนวโน้มจะส่ง IR ที่พองเกินจำเป็น ไปให้ LLVM ด้วย ซึ่งยิ่งไม่ช่วย
    • ขอบคุณครับ :) ดูเหมือนว่าคนมีมุมมองต่อเวลาในการคอมไพล์ Rust ต่างกันมาก บางคนโทษ การตรวจชนิด บางคนโทษ LLVM
      เป้าหมายระยะกลางของผม หรือประมาณ 5 ปีจากนี้ คือ cargo check ดังนั้นจะยังไม่แตะการสร้างโค้ด
      ถึงอย่างนั้นผมก็ยังคิดว่ามีช่องให้ปรับแต่งได้ อีกมาก ในเรื่อง parallelism ที่ดีกว่าเดิม, การแยก hot path ของโค้ดวินิจฉัย, การลดงานซ้ำซ้อนระหว่าง type checking กับ borrow checking และการปรับปรุงการจัดวางหน่วยความจำของโครงสร้างข้อมูลหลัก
      การที่ผมสนิทกับนักพัฒนา rustc และได้ยินปัญหาหลายอย่างในโค้ดเบสบ่อย ๆ ก็ช่วยมากเหมือนกัน
    • rustc มี Cranelift backend
    • ดูเหมือนว่า LLVM จะเป็นส่วนที่ช้าจริง ๆ ผมก็เห็นแนวโน้มแบบนั้นในวงสนทนาเรื่องเวลาในการคอมไพล์ของ Zig เช่นกัน และ implementation ทางเลือกแบบ self-hosted ก็เร็วกว่า LLVM มากพอสมควร1