FFMpeg, ประสิทธิภาพเพิ่มขึ้น 94 เท่าด้วยโค้ดแอสเซมบลี AVX-512 ที่เขียนด้วยมือ

• ภาษาโปรแกรมระดับสูงและคอมไพเลอร์ขั้นสูงในยุคปัจจุบันช่วยให้การพัฒนาซอฟต์แวร์ง่ายขึ้นมากและลดต้นทุนลง แต่ก็มักซ่อนศักยภาพด้านประสิทธิภาพของฮาร์ดแวร์สมัยใหม่ไว้เนื่องจากความไม่มีประสิทธิภาพของ API
• ตามที่นักพัฒนา FFmpeg ระบุ การใช้โค้ดแอสเซมบลีสามารถเพิ่มประสิทธิภาพได้ตั้งแต่ 3 เท่าถึง 94 เท่า ขึ้นอยู่กับเวิร์กโหลด
• เพื่อเร่งความเร็วฟังก์ชันบางอย่างใน FFmpeg ได้มีการสร้างเส้นทางโค้ดที่ปรับแต่งด้วยชุดคำสั่ง AVX-512 และสามารถทำประสิทธิภาพได้เร็วกว่าการติดตั้งใช้งานมาตรฐานอย่างมาก
• AVX-512 ใช้รีจิสเตอร์ 512 บิต จึงสามารถประมวลผล single-precision FLOP ได้ 16 ค่า หรือ double-precision FLOP ได้ 8 ค่าในการดำเนินการครั้งเดียว ทำให้จัดการข้อมูลจำนวนมากแบบขนานได้
• จากผลการเบนช์มาร์ก เส้นทางโค้ด AVX-512 ที่เขียนด้วยมือใหม่นั้นเร็วกว่าทั้งโค้ด C ต้นแบบและการติดตั้งใช้งานอื่น ๆ ที่ใช้ชุดคำสั่ง SIMD ระดับต่ำกว่า เช่น AVX2 และ SSE3 อย่างชัดเจน
• การพัฒนานี้มีประโยชน์อย่างยิ่งต่อผู้ใช้ที่รันบนฮาร์ดแวร์ที่รองรับ AVX-512 และช่วยให้ประมวลผลคอนเทนต์สื่อได้อย่างมีประสิทธิภาพยิ่งขึ้นมาก
• อย่างไรก็ตาม Intel ได้ปิดใช้งาน AVX-512 บนโปรเซสเซอร์ Core รุ่นที่ 12, 13 และ 14 ทำให้เจ้าของ CPU เหล่านี้ไม่สามารถใช้งานได้
• ในทางกลับกัน CPU ซีรีส์ Ryzen 9000 ของ AMD มาพร้อม FPU สำหรับ AVX-512 ที่เปิดใช้งานเต็มรูปแบบ ดังนั้นเจ้าของโปรเซสเซอร์เหล่านี้จึงสามารถใช้ประโยชน์จากผลงานของ FFmpeg ได้
• น่าเสียดายที่เนื่องจากความซับซ้อนและความเฉพาะทางของ AVX-512 การเพิ่มประสิทธิภาพลักษณะนี้จึงมักจำกัดอยู่ในแอปพลิเคชันที่ให้ความสำคัญกับประสิทธิภาพ และต้องอาศัยความเชี่ยวชาญด้านการเขียนโปรแกรมระดับล่างและไมโครสถาปัตยกรรมของโปรเซสเซอร์
  ( เนื้อหานี้นำมาจาก Tom's Hardware: FFmpeg devs boast of up to 94x performance boost after implementing handwritten AVX-512 assembly code )

[gurugio]

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

[GN⁺]

ความเห็นจาก Hacker News

• คำกล่าวอ้างว่าประสิทธิภาพดีขึ้น 94 เท่าในฟิลเตอร์บางตัวของ FFmpeg นั้นชวนให้เข้าใจผิด ผู้ใช้ส่วนใหญ่ใช้ AVX/SSE กันอยู่แล้ว จึงไม่ได้ต้องการการปรับแต่งโค้ด C มากนัก
  • การใช้ CPU หลักของ FFmpeg คือการเข้ารหัสและถอดรหัส และการปรับปรุงครั้งนี้ไม่ได้ส่งผลต่อส่วนดังกล่าว
• นี่ไม่ใช่การเปรียบเทียบระหว่างแอสเซมบลีที่เขียนด้วยมือกับโค้ดที่ไม่ได้เขียนแบบนั้น แต่เป็นการเปรียบเทียบระหว่างโค้ดสเกลาร์กับโค้ดเวกเตอร์
  • หากเขียนโค้ด C ด้วย AVX intrinsics ก็สามารถได้ความเร็วเพิ่มขึ้นใกล้เคียงกันโดยไม่ต้องใช้แอสเซมบลี
• ในบางกรณี แอสเซมบลีที่เขียนด้วยมืออาจได้เปรียบ
  • ตัวถอดรหัสวิดีโอมีลูปที่กระชับมาก จึงอาจต้องใช้แอสเซมบลีเพื่อรักษาความสม่ำเสมอของประสิทธิภาพ
• ทีม FFmpeg ไม่อนุญาตให้ใช้ intrinsics และกำหนดให้โค้ดเฉพาะแพลตฟอร์มทั้งหมดเขียนเป็นแอสเซมบลี
  • แอสเซมบลีจะเร็วกว่าเสมอหากทุ่มเทมากพอ แต่ intrinsics ก็ให้ประสิทธิภาพที่ใกล้เคียงมากได้ด้วยความพยายามน้อยกว่า
• การปรับปรุง 94 เท่าเป็นการเพิ่มประสิทธิภาพของ dav1d และไม่ได้ใช้ได้แค่กับ FFmpeg แต่ใช้กับโปรแกรมอื่นได้ด้วย
  • มีคำขอสำหรับการปรับแต่งบน RISC-V (64 บิต) ซึ่งเป็นโอกาสที่ดีสำหรับผู้ที่สนใจ
• Mike Pall แห่ง LuaJIT เคยอธิบายข้อดีของการเขียนแอสเซมบลีไว้แล้ว
• ในไมโครบेंช์มาร์ก ฟังก์ชันเดี่ยวหนึ่งตัวเร็วกว่าโค้ด C ถึง 94 เท่า
• Intel ปิดใช้งาน AVX-512 บนโปรเซสเซอร์ Core รุ่นที่ 12, 13 และ 14
  • ยังหาสาเหตุที่ชัดเจนสำหรับเรื่องนี้ไม่ได้
• หลายครั้งมีการแก้ปัญหาด้านประสิทธิภาพก่อนจะระบุคอขวดได้ชัดเจนเพียงพอ
  • โค้ด C ส่วนใหญ่มักถูกคอมไพล์เป็นแอสเซมบลีที่เหมาะสมอยู่แล้ว
• สาเหตุของประสิทธิภาพที่เพิ่มขึ้นไม่ใช่แอสเซมบลีที่เขียนด้วยมือ แต่เป็นการใช้คำสั่ง SIMD ของ AVX-512
  • อยากเห็นการเปรียบเทียบกับการเวกเตอร์ไรซ์ AVX-512 ของ gcc

[maclier]

ช่องโหว่ใหม่ของ Intel Downfall ใน AVX2/AVX-512 และผลกระทบด้านประสิทธิภาพอย่างมหาศาลที่เกิดจากมัน

https://tuxcare.com/ko/blog/…

[cosine20]

อ้อ เพราะแบบนี้เอง Intel ถึงถอด AVX-512 ออกไปสินะ

[shlee1503]

เท่าที่ทราบ น่าจะเป็นเพราะ E-core ไม่รองรับ AVX-512 จึงถูกปิดกั้นไว้ด้วยซอฟต์แวร์มากกว่าจะเป็นเหตุผลนั้น
ส่วน P-core เคยรองรับ AVX-512 แบบไม่เป็นทางการอยู่ครับ

[cosine20]

เข้าใจแล้วครับ ขอบคุณที่บอกนะครับ :)