โครงการ CPU Deoptimization ค้นหาคำสั่ง x86 ช้าที่สุด บันทึก fxrstor64 ใช้ 62 วินาที

Lead: นักวิจัยฮาร์ดแวร์ชาวอเมริกา Christopher Domas เปิดตัวโครงการ CPU Deoptimization เพื่อค้นหาคำสั่งระดับ Assembly ที่ทำงานช้าที่สุดบนสถาปัตยกรรม x86 ผลลัพธ์แรกพบว่าคำสั่ง fxrstor64** ใช้เวลาถึง 62 วินาที หรือกว่า 198 พันล้านไซเคิล*—ตัวเลขที่ทำให้ผู้พัฒนาซอฟต์แวร์และสถาปัตยกรรมนิ่งเนิ่นชัดถึงขอบเขตการทำงานของ CPU ที่อาจถูกบังคับให้อยู่ใน “โหมดช้า” อย่างสุดโต่ง*

Overview

โครงการ CPU Deoptimization มีเป้าหมายหลักคือวัด latency สูงสุดของคำสั่งเดียวโดยให้คอมพิวเตอร์ทำงานอย่างช้าที่สุดเท่าที่เป็นไปได้ ไม่เหมือนการวิจัยทั่วไปที่มุ่งปรับปรุงประสิทธิภาพ การหาคำสั่ง “แย่ที่สุด” นี้ช่วยให้เห็นจุดอ่อนในโครงสร้างของ CPU ที่อาจถูกนำไปใช้เพื่อทดสอบความเสถียรหรือจำลองสถานการณ์โหลดหนักอย่างเป็นระบบ ตามที่ Domas ระบุในบล็อก GitHub ของโครงการ

การทำงานเริ่มจากการใช้เครื่องมือ mmiotic เพื่อระบุตำแหน่งที่มี latency สูงภายใน PCIe fabric ของ CPU แล้วสร้างสภาพแวดล้อมให้คำสั่งต้องอ่านข้อมูลจาก MMIO (Memory‑Mapped I/O) ขนาด 512 byte อย่างช้า ๆ ขั้นตอนต่อไปคือการ “ทำให้อิ่ม” แบนด์วิธของ PCIe ด้วยการเรียกอ่านแบบ 4 byte จากรีจิสเตอร์อื่นที่มี latency สูง ทำให้คำสั่งหลักต้องรอคิวจนเกิดความล่าช้าอย่างมหาศาล

ผลลัพธ์เบื้องต้นแสดงว่าเมื่อใช้ fxrstor64 ร่วมกับเทคนิคดังกล่าวแล้ว คำสั่งสามารถทำงานได้นาน 62 วินาที หรือกว่า 198 พันล้านไซเคิล ซึ่งถือเป็นบันทึกใหม่ของ “slowest single instruction” บนแพลตฟอร์ม x86 จนถึงปัจจุบัน

Methodology

กระบวนการทดสอบอาศัยหลายขั้นตอนที่ซับซ้อนแต่ยังคงยึดหลักความเป็นธรรม:

• ค้นหา latency hotspot ด้วย mmiotic เพื่อระบุส่วนของ PCIe ที่ทำงานช้าที่สุด
• สร้าง MMIO load โดยให้ CPU โหลดข้อมูล 512 byte จากตำแหน่ง memory‑mapped ทำให้ต้องประมวลผล byte‑by‑byte อย่างช้า ๆ
• ทำให้อิ่ม PCIe fabric ด้วยการอ่านรีจิสเตอร์ขนาด 4 byte จำนวนหลายร้อยครั้งจากอุปกรณ์อื่นที่มี latency สูงเพื่อบังคับให้คำสั่งหลักคอยในคิว

หลังจากขั้นตอนเหล่านี้ Domas ยังทดลองใช้ชุดคำสั่ง AMX ของ Intel Sapphire Rapids (เช่น xrstore64) เพื่อขยายพื้นที่สถานะเป็น 8 KB ซึ่งอาจทำให้การทำงาน “hang” ไปเกิน 1 trillion cycles* หากเทคนิคเดียวกันถูกนำไปใช้ต่อเนื่อง

ทุกขั้นตอนทำบนระบบที่ไม่มีการปรับแต่งฮาร์ดแวร์เพิ่มเติมและค่าผลลัพธ์จะถูก normalize ตามความถี่ฐานของ CPU เพื่อให้เปรียบเทียบได้อย่างเป็นมาตรฐานระหว่างแพลตฟอร์มต่าง ๆ

Results & Records

ผลการทดสอบที่สำคัญที่สุดคือคำสั่ง fxrstor64 ซึ่งทำหน้าที่กู้คืนสถานะของรีจิสเตอร์ SIMD ไปยังหน่วยความจำขนาด 512 byte ในสภาพแวดล้อมที่ถูก “starved” ด้วย MMIO reads ทำให้ใช้เวลา 62 seconds หรือ 198,002,498,236 cycles

นอกจากนี้ ยังมีบันทึกย่อยที่น่าสนใจ:

• คำสั่ง rdmsr บนชิป VIA Eden (รุ่นต้นศตวรรษ 2000) ใช้เวลา 202 microseconds หรือประมาณ 161,602 cycles* เนื่องจากการเข้าถึงรีจิสเตอร์ที่ไม่ได้เปิดเผยในเอกสารอย่างเป็นทางการ (address 0x133)
• การทดสอบบน Intel Core i7‑8559U และ AMD Ryzen 7 5800H (ใน Trigkey S5) ให้ผลลัพธ์คล้ายกันเมื่อใช้เทคนิคเดียวกัน, แสดงว่าความช้าสามารถทำได้โดยไม่ต้องพึ่งสถาปัตยกรรมเฉพาะเจาะจง

Domas ยังเปิดเผยว่าโครงการจะขยายไปยัง ARM และ RISC‑V ในอนาคต ซึ่งอาจนำมาซึ่ง “hall of shame” ของคำสั่งช้าที่สุดบนแพลตฟอร์มอื่น ๆ ด้วยเช่นกัน

Rules & Platform

เพื่อรักษาความเป็นธรรมและความเที่ยงตรงของลีดเดอร์บอร์ด Domas กำหนดกฎเกณฑ์หลายประการ:

• การตั้งค่าระบบใดก็ได้ ตราบใดที่ผลลัพธ์วัดจากการทำงานของคำสั่งเดียว
• ไม่อนุญาตให้ใช้ interruptible instructions หรือคำสั่งที่อาจถูกขัดจังหวะระหว่างดำเนินการ
• ห้ามนับเวลาคำสั่งที่รันบน emulated handlers หรือซอฟต์แวร์จำลองอื่น ๆ
• ผลลัพธ์ต้อง normalize ตามความถี่ฐานของ CPU และทำบนแพลตฟอร์มที่ไม่มีการดัดแปลงฮาร์ดแวร์

โดยส่วนใหญ่แล้วการทดสอบดำเนินการบนสองโปรเซสเซอร์หลัก:

• Intel Core i7‑8559U – โปรเซสเซอร์แบบ mobile ที่ใช้สถาปัตยกรรม Coffee Lake
• AMD Ryzen 7 5800H – โปรเซสเซอร์สำหรับโน๊ตบุ๊คระดับสูงบนสถาปัตยกรรม Zen 3

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

Historical Context & Analysis

โครงการ CPU Deoptimization ไม่ใช่ครั้งแรกของ Domas ที่ทดลองกับคำสั่งระดับต่ำ เขาเคยสร้าง movfuscator ซึ่งเป็นคอมไพเลอร์ C ที่แปลงโค้ดทั้งหมดให้ใช้เพียงคำสั่ง mov เท่านั้น การทำเช่นนี้ชี้ให้เห็นถึงความสนใจในการสำรวจขอบเขตของสถาปัตยกรรมโดยการบังคับให้ระบบทำงานในรูปแบบที่ “ผิดธรรมชาติ”

จากมุมมองของอุตสาหกรรม การรู้จักคำสั่งที่ช้าที่สุดมีประโยชน์หลายด้าน:

• สามารถใช้เป็น benchmark เพื่อตรวจสอบว่าโซลูชั่นการออกแบบใหม่หรือระบบจัดการพลังงานทำให้ latency แย่ลงหรือไม่
• ช่วยนักวิจัยค้นหาจุดบกพร่องของ firmware หรือ microcode ที่อาจถูกโจมตีโดยการทำ Denial‑of‑Service ระดับฮาร์ดแวร์
• ให้ข้อมูลเชิงลึกต่อผู้พัฒนา compiler ว่าคำสั่งใดควรหลีกเลี่ยงหรือจัดเรียงใหม่เพื่อป้องกัน bottleneck

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

Impact

แม้ว่าโครงการจะดูเหมือนกิจกรรม “ขำขัน” ในวงการฮาร์ดแวร์, การเผยแพร่ข้อมูลนี้อาจกระตุ้นให้ผู้ผลิต CPU พิจารณา latency corner cases ที่เคยมองข้าม ตัวอย่างเช่น การจัดการกับ MMIO accesses ที่มี latency สูงหรือการควบคุม PCIe root complex ภายใต้โหลดหนัก

นอกจากนี้ การที่ Domas วางแผนสร้างลีดเดอร์บอร์ดสำหรับ ARM และ RISC‑V จะทำให้ชุมชนวิจัยได้เห็นภาพรวมของคำสั่ง “slowest” ข้ามสถาปัตยกรรม ซึ่งอาจนำไปสู่การพัฒนามาตรฐานใหม่ในการวัด latency อย่างเป็นระบบ

สุดท้าย การเปิดเผยข้อมูลเหล่านี้บน GitHub ทำให้ open‑source community สามารถทำซ้ำ, ตรวจสอบ, หรือขยายผลได้โดยตรง ซึ่งส่งเสริมหลักการของความโปร่งใสและการร่วมมือทางเทคนิคในระดับโลก

Summary

โครงการ CPU Deoptimization ของ Christopher Domas ค้นพบว่าคำสั่ง fxrstor64 ใช้เวลาถึง 62 วินาที หรือกว่า 198 พันล้านไซเคิลในการทำงานบนแพลตฟอร์ม x86 ทำให้เกิด “hall of shame” แรกของคำสั่งช้าที่สุด การทดลองนี้เปิดเผยแนวทางใหม่ในการประเมิน latency ของ CPU และอาจมีผลต่อการออกแบบและตรวจสอบระบบฮาร์ดแวร์ในอนาคต.