ISAMORE: การสร้างคำสั่งกำหนดเองของ RISC-V อัตโนมัติโดยใช้ E-Graph Anti-Unification เปิดแนวทางใหม่ในการออกแบบฮาร์ดแวร์ AI

คำสำคัญ: คำสั่งที่กำหนดเอง, RISC-V, E-Graph, การต่อต้านการรวม, การเร่งความเร็วด้วย AI, DSA

บทความนี้ไม่เพียงแต่แนะนำเครื่องมือโอเพ่นซอร์สที่ทรงพลังเท่านั้น แต่ที่สำคัญกว่านั้นคือ มันแสดงให้เห็นถึงการเปลี่ยนแปลงทางความคิด: ในยุคของการออกแบบร่วมระหว่างซอฟต์แวร์และฮาร์ดแวร์ ทรัพยากรที่มีค่าที่สุดไม่ใช่ทรานซิสเตอร์ แต่คือการนำรูปแบบการออกแบบและความรู้กลับมาใช้ใหม่ได้ โดยเฉพาะอย่างยิ่ง แนวคิดสำหรับโครงสร้างพื้นฐาน AI และชุมชนการออกแบบชิปมีดังนี้:

1. เกิดมาเพื่อวิวัฒนาการของอัลกอริทึม: ในยุคหลังมัวร์ อัลกอริทึมวิวัฒนาการเร็วกว่าการเปลี่ยนแปลงของฮาร์ดแวร์ ดังนั้นจึงจำเป็นต้องมีเครื่องมืออัตโนมัติเพื่อเชื่อมโยง “อัลกอริทึมที่เปลี่ยนแปลงอย่างรวดเร็ว” กับ “ฮาร์ดแวร์ที่ค่อนข้างคงที่” ทำให้การออกแบบชิปสามารถปรับตัวได้อย่างยืดหยุ่น แทนที่จะยึดติดกับวิธีเดิม
2. ก้าวข้าม “วิศวกรรมคุณลักษณะด้วยมือ”: คอมไพเลอร์และเฟรมเวิร์กการสร้างคำสั่งอัตโนมัติจะสามารถวิเคราะห์กราฟการคำนวณโดยอัตโนมัติ แยกแยะ “การดำเนินการระดับอะตอม” และสร้างหน่วยเร่งความเร็วฮาร์ดแวร์ที่สอดคล้องกันได้แบบไดนามิก
3. สร้าง “ระบบนิเวศของคำสั่ง” ที่เปิดกว้าง: RISC-V เปิดสถาปัตยกรรมชุดคำสั่ง ในอนาคต โดเมนต่างๆ สามารถ “เติบโต” ชุดคำสั่งที่เหมาะสมที่สุดและสามารถแบ่งปันได้จากระบบนิเวศซอฟต์แวร์ของตนเอง ส่งผลให้เกิดระบบนิเวศของคำสั่งที่กำหนดเองที่เจริญรุ่งเรือง

บทนำ

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

นี่ดูเหมือนจะเป็นทางออกที่สมบูรณ์แบบ อย่างไรก็ตาม ความเป็นจริงมักจะซับซ้อนกว่านั้น: เมื่อทีมอื่นเร่งความเร็วงานประมวลผลคลาวด์จุด ซอฟต์แวร์ของพวกเขามักจะมีรูปแบบการคำนวณที่เทียบเท่ากันทางความหมาย แต่มีรูปแบบทางไวยากรณ์เป็น (a+b)/(c+d) ในขณะที่คำสั่งที่กำหนดเอง Softmax ที่มีอยู่ไม่สามารถเร่งความเร็วได้

สิ่งนี้นำไปสู่ปัญหาหลัก: คำสั่งที่กำหนดเองที่เราออกแบบ เป็นเพียงการเพิ่มประสิทธิภาพเฉพาะกิจ หรือเป็นหน่วย “บล็อกก่อสร้าง” ที่สามารถรวมกันได้อย่างยืดหยุ่นและนำกลับมาใช้ใหม่ได้อย่างกว้างขวาง?

ในปัจจุบันที่ระบบนิเวศ RISC-V เติบโตอย่างรวดเร็ว การออกแบบคำสั่งที่กำหนดเองที่สามารถขยายได้นั้นสะดวกกว่าที่เคย แต่จะค้นหารูปแบบคำสั่งที่ใช้บ่อย นำกลับมาใช้ใหม่ได้ และใช้ประโยชน์จากการประมวลผลแบบขนานระดับข้อมูลได้อย่างเต็มที่จากแอปพลิเคชันโดยอัตโนมัติได้อย่างไร ยังคงเป็นความท้าทายที่ยิ่งใหญ่ วิธีการที่มีอยู่มักจำกัดอยู่ที่การจับคู่ในระดับไวยากรณ์ หรือละเลยความเท่าเทียมกันทางความหมาย ส่งผลให้คำสั่งที่สร้างขึ้นมีความเฉพาะทางสูงและอัตราการนำกลับมาใช้ใหม่ต่ำ

ทีมจากมหาวิทยาลัยปักกิ่งได้เสนอกรอบงานใหม่ชื่อ ISAMORE ในบทความที่ตีพิมพ์ใน ASPLOS’26 เรื่อง “Finding Reusable Instructions via E-Graph Anti-Unification” ข้อมูลเชิงลึกหลักของงานนี้คือ: ความสามารถในการนำกลับมาใช้ใหม่ที่แท้จริงซ่อนอยู่ในความเท่าเทียมกันทางความหมายของโปรแกรม ไม่ใช่ความคล้ายคลึงกันทางไวยากรณ์บนพื้นผิว

เพื่อจุดประสงค์นี้ นักวิจัยได้แนะนำเทคนิคที่ทรงพลังที่เรียกว่า E-Graph Anti-Unification เทคนิคนี้สามารถแยกแยะ “รูปแบบการคำนวณ” ร่วมที่อยู่เบื้องหลังจากโค้ดส่วนต่างๆ ได้โดยอัตโนมัติ เหมือนกับการค้นหากฎพีชคณิต

Anti-Unification เป็นเทคนิคที่แยกโครงสร้างร่วมจากสองนิพจน์ที่แตกต่างกัน โดยทำให้ส่วนที่แตกต่างกันเป็นตัวแปร ตัวอย่างเช่น a×2+b×2 และ (1+i)×2 หลังจาก Anti-Unification จะได้ (?x+?y)×2 ผลลัพธ์นี้สรุปรูปแบบร่วมของ “การบวกสองตัวเลขแล้วคูณด้วย 2” โดยไม่สนใจตัวถูกดำเนินการเฉพาะเจาะจง ด้วยวิธีนี้ สามารถค้นพบคำสั่งที่นำกลับมาใช้ใหม่ซึ่งมีความหมายเหมือนกันในโค้ดที่แตกต่างกัน

ผลการทดลองแสดงให้เห็นว่า เมื่อเทียบกับวิธีการรวมทางไวยากรณ์แบบดั้งเดิม จำนวนครั้งโดยเฉลี่ยที่แต่ละคำสั่งที่ค้นพบโดย ISAMORE ถูกนำกลับมาใช้ใหม่เพิ่มขึ้นจากน้อยกว่า 9 ครั้งเป็น 93 ครั้ง ในขณะที่บรรลุการเพิ่มประสิทธิภาพสูงสุด 2.69 เท่า ยังสามารถประหยัดพื้นที่ฮาร์ดแวร์ได้มากกว่า 90%

บทความนี้จะเจาะลึก ISAMORE สำรวจว่ามันใช้เทคโนโลยี E-Graph และ Anti-Unification จากสาขาวิธีการที่เป็นทางการเพื่อเปิดเส้นทางใหม่สำหรับการออกแบบชิป AI ที่เป็นอัตโนมัติ ฉลาด และมีระดับการนำกลับมาใช้ใหม่สูงได้อย่างไร

ประเด็นสำคัญ

ปัญหาที่ 1: การตัดแต่งแบบฮิวริสติกอาจพลาดรูปแบบที่มีคุณค่าสูงซึ่งมีโครงสร้างต่างกันแต่เทียบเท่ากันทางความหมายหรือไม่?

ในการเพิ่มประสิทธิภาพคอมไพเลอร์จริง ส่วนโค้ดที่ใช้ฟังก์ชันการคำนวณเดียวกันอาจแตกต่างกันอย่างมีนัยสำคัญในโครงสร้าง เช่น ลูปกับการคลี่ลูป การตั้งชื่อตัวแปร หรือวิธีการพับค่าคงที่ รูปแบบที่แตกต่างกันเหล่านี้ในหน่วยวัดความคล้ายคลึงกันแบบแฮชไวยากรณ์ (เช่น ระยะทาง Jaccard) อาจได้คะแนนต่ำมาก และถูกกรองออกโดยเกณฑ์การตัดแต่งที่กำหนดไว้ล่วงหน้า บทความใช้วิธีการแบบฮิวริสติก โดยทำ Anti-Unification เฉพาะกับคู่ e-class ที่มีความคล้ายคลึงเกินเกณฑ์เฉพาะ และเสริมด้วยกลยุทธ์การสุ่มตัวอย่างรูปแบบแบบขอบเขตหรือ kd-tree สิ่งนี้ทำให้เกิดความกังวลหลัก: ระบบจะพลาดรูปแบบที่มีคุณค่าสูงซึ่ง “เทียบเท่ากันทางความหมายแต่มีโครงสร้างต่างกัน” หรือไม่? หากกระบวนการ Anti-Unification ไม่มีความสมบูรณ์ แล้วข้อได้เปรียบที่อ้างว่า “รับรู้ความหมาย” จะลดทอนลงเป็นเพียงการประมาณทางไวยากรณ์อีกแบบหนึ่งโดยพื้นฐานหรือไม่?

ผู้เขียนชี้แจงอย่างชัดเจนว่าการตัดแต่งแบบฮิวริสติกเป็นข้อประนีประนอมที่จำเป็นสำหรับความเป็นไปได้ทางวิศวกรรม หากทำ Anti-Unification แบบสมบูรณ์สำหรับทุกคู่ e-class จำนวนรูปแบบผู้สมัครจะเพิ่มขึ้นอย่างรวดเร็วเป็นมากกว่า 633,000 รูปแบบ ทำให้การใช้หน่วยความจำเกิน 30GB และอัลกอริทึมไม่สามารถทำงานได้จริง เมื่อเปิดใช้งานการตัดแต่งแบบฮิวริสติก การทดสอบมาตรฐานทั้งหมดสามารถทำเสร็จภายใน 145 วินาที โดยใช้หน่วยความจำควบคุมภายใน 799MB นี่เป็นข้อแลกเปลี่ยนที่เสียสละความสมบูรณ์ทางทฤษฎีเพื่อแลกกับความสามารถในการปรับขนาดของอัลกอริทึม

เกี่ยวกับว่าจะพลาดรูปแบบสำคัญหรือไม่ การทดลองให้หลักฐานทางอ้อม: ในมาตรฐาน QProd, Deriche ฯลฯ กลยุทธ์ KDSample ที่ใช้การสุ่มตัวอย่างที่หลากหลายกว่ามีประสิทธิภาพดีกว่ากลยุทธ์ขอบเขตเริ่มต้น นี่แสดงให้เห็นว่ากลยุทธ์ขอบเขตอาจกรองรูปแบบที่มีประโยชน์บางอย่างออกไปจริง อย่างไรก็ตาม แม้จะดังนั้น อัตราการเร่งความเร็วโดยรวมของ ISAMORE ยังคงอยู่ที่ 1.12 ถึง 2.69 เท่า ซึ่งดีกว่าวิธีพื้นฐานที่มีอยู่

สรุป: การตัดแต่งแบบฮิวริสติกมีความเสี่ยงที่จะพลาดรูปแบบที่มีคุณค่าสูงจริง แต่เป็นข้อแลกเปลี่ยนทางวิศวกรรมที่จำเป็นระหว่างประสิทธิภาพและความสมบูรณ์ บทความไม่ได้แสวงหาการรับรู้ความหมายที่สมบูรณ์แบบ แต่บรรลุการเพิ่มประสิทธิภาพที่สำคัญในขอบเขตที่ยอมรับได้

ปัญหาที่ 2: การตัดแต่งแบบละโมบขัดแย้งกับเป้าหมาย “การนำกลับมาใช้ใหม่สูงสุด” หรือไม่?

ความท้าทายหลักของการทำให้รูปแบบเป็นเวกเตอร์คือการแยกการประมวลผลแบบขนานระดับข้อมูล (DLP) ออกจากโปรแกรมสเกลาร์ บทความใช้กลยุทธ์แบบละโมบ โดยเลือกตัวสร้างเวกเตอร์ที่มีผลตอบแทน DLP สูงก่อน และดำเนินการ compress เพื่อทำให้แผนการทำให้เป็นเวกเตอร์ที่เลือกไว้คงที่ใน e-graph พร้อมทั้งละทิ้งชุดค่าผสมการทำให้เป็นเวกเตอร์อื่นๆ ที่เป็นไปได้ การตัดแต่งแบบละโมบนี้แม้จะกำจัดลูป Get→Vec→Get และควบคุมขนาดของ e-graph ได้ แต่ก็ล็อกกลยุทธ์การทำให้เป็นเวกเตอร์เดียวไว้ก่อน ชุดเมล็ดพันธุ์ที่แตกต่างกันอาจสอดคล้องกับคำสั่งเวกเตอร์ที่มีพื้นที่ฮาร์ดแวร์ ความล่าช้า และความถี่ในการนำกลับมาใช้ใหม่ที่แตกต่างกันอย่างมาก ตัวอย่างเช่นใน 2DConv LLVM ไม่ทำ if-conversion ทำให้การตรวจสอบขอบเขตขัดขวางการทำให้เป็นเวกเตอร์ แต่หากใช้กลยุทธ์ที่แตกต่างกัน เช่น การแพ็คข้ามบล็อกพื้นฐาน อาจยังสามารถแยกรูปแบบที่มีประสิทธิภาพได้ การตัดแต่งแบบละโมบนี้ขัดแย้งโดยเนื้อแท้กับเป้าหมายพื้นฐานของ “โอกาสในการนำกลับมาใช้ใหม่สูงสุด” หรือไม่? อาจทำให้แอปพลิเคชันบางอย่างไม่สามารถบรรลุการแลกเปลี่ยนระหว่างความเร็วและพื้นที่ที่ดีที่สุดในทางทฤษฎีหรือไม่?

ผู้เขียนยอมรับว่าการตัดแต่งแบบละโมบอาจพลาดโอกาสการทำให้เป็นเวกเตอร์บางส่วน อย่างไรก็ตาม นี่เป็นสิ่งที่หลีกเลี่ยงไม่ได้: หากไม่ตัดแต่ง e-graph ที่ผสมผสานระหว่างสเกลาร์และเวกเตอร์จะสร้างลูป Get→Vec→Get จำนวนมาก ทำให้ขนาดกราฟขยายตัวแบบทวีคูณ และทำให้กระบวนการ Anti-Unification และการแยกที่ตามมาไม่สามารถดำเนินการได้ นี่เป็นกลยุทธ์ "เลือกโทษที่เบากว่า" – เสียสละแผนการทำให้เป็นเวกเตอร์ที่อาจเป็นไปได้บางส่วน เพื่อให้แน่ใจว่ากระบวนการอัตโนมัติทั้งหมดสามารถดำเนินการได้อย่างราบรื่น