บทเรียนภาษาแอสเซมบลีของ FFmpeg

 (github.com/FFmpeg)
3 คะแนน โดย GN⁺ 2025-08-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทเรียนภาษาแอสเซมบลีของ FFmpeg เป็นสื่อการเรียนรู้โอเพนซอร์สที่ออกแบบมาเพื่อช่วยให้เข้าใจการทำงานภายในของคอมพิวเตอร์ได้อย่างลึกซึ้ง
  • รีโพซิทอรีนี้มีทั้งตัวอย่างจริงของ ภาษาแอสเซมบลีที่ใช้ใน FFmpeg และแบบฝึกหัดที่เน้นการลงมือปฏิบัติ
  • ผู้เรียนควรมีความรู้พื้นฐานเกี่ยวกับ พอยน์เตอร์ในภาษา C และ คณิตศาสตร์ระดับมัธยมปลาย
  • จากสิ่งนี้ ผู้เรียนจะสามารถพัฒนาความสามารถในการ มีส่วนร่วมโดยตรง กับโปรเจกต์โอเพนซอร์ส FFmpeg ได้
  • มีการสนับสนุนสำหรับการถามคำถามและการอภิปรายผ่าน ช่อง Discord

แนะนำบทเรียนภาษาแอสเซมบลีของ FFmpeg

  • FFmpeg School of Assembly Language เป็นบทเรียนโอเพนซอร์สที่สร้างขึ้นเพื่อให้คุณได้เริ่มต้นการเดินทางที่น่าสนใจ ท้าทาย และคุ้มค่าที่สุดอย่างหนึ่งในโลกของการเขียนโปรแกรม
  • ผ่านบทเรียนนี้ คุณจะได้เรียนรู้จากโค้ดจริงว่า ภาษาแอสเซมบลีถูกเขียนอย่างไรใน FFmpeg และสามารถทำความเข้าใจอย่างเป็นระบบว่าเกิดอะไรขึ้นภายในคอมพิวเตอร์

ความรู้ที่ต้องมี

  • จำเป็นต้องมีความเข้าใจเกี่ยวกับ ภาษา C โดยเฉพาะแนวคิดเรื่องพอยน์เตอร์
    • หากยังไม่รู้ภาษา C อาจต้องศึกษาหนังสือ "The C Programming Language" ก่อน
  • ควรมีความรู้ คณิตศาสตร์ระดับมัธยมปลาย (สเกลาร์ เวกเตอร์ การบวก การคูณ เป็นต้น)

โครงสร้างบทเรียนและวิธีใช้งาน

  • ใน GitHub repository นี้มีบทเรียนแบบเป็นขั้นตอนและโจทย์ที่สอดคล้องกับแต่ละบทเรียนรวมอยู่ด้วย (โจทย์ยังไม่ได้อัปโหลด)
  • เมื่อเรียนจบทั้งหมดแล้ว คุณจะมี ทักษะเชิงปฏิบัติที่พร้อมสำหรับการมีส่วนร่วมโดยตรง กับโปรเจกต์ FFmpeg

การสนับสนุนจากชุมชน

การแปลหลายภาษา

  • บทเรียนนี้ยังมีให้ใช้งานในภาษาฝรั่งเศสและภาษาสเปนด้วย ทำให้นักพัฒนาจากหลากหลายภาษาสามารถเข้าถึงได้ง่ายขึ้น

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

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

 
GN⁺ 2025-08-19
ความเห็นจาก Hacker News
  • แค่จินตนาการถึงขนาดของ FFMPEG ก็รู้สึกทึ่งแล้ว แม้การปรับปรุงประสิทธิภาพเพียงเล็กน้อยก็ช่วยประหยัดเวลาการประมวลผลได้เป็นหลักพันหรือหลักหมื่นชั่วโมง เป็นโปรเจ็กต์ที่มีประโยชน์มากจริงๆ
    • คิดว่าความหมกมุ่นของทีม FFMPEG ที่มีต่อประสิทธิภาพนั้นยอดเยี่ยมมาก ถ้าทุกโปรเจ็กต์มีท่าทีแบบนั้นคงดีไม่น้อย
    • แต่อีกใจก็อยากให้มี API ที่ชัดเจนในความหมายดั้งเดิมบ้าง (ไม่ใช่แบบเชิงคำสั่ง แต่เป็นไลบรารีจริงๆ) เพราะการทำความเข้าใจ command line ที่เหมือนภาษาของตัวเองแบบตอนนี้ไม่ง่ายเลย
  • มีการพูดคุยก่อนหน้านี้เมื่อ 2025-02-22 โดยมี 222 ความเห็น ดูได้ที่นี่
  • สงสัยว่าในทางปฏิบัติเขาหา hotspot ที่เกิดจากแอสเซมบลีที่คอมไพเลอร์สร้างแบบไม่เหมาะสมกันอย่างไร และก็สงสัยด้วยว่าการเขียน intermediate representation อย่าง LLVM IR โดยตรงแทนแอสเซมบลีเฉพาะสถาปัตยกรรมจะมีความหมายหรือไม่
    • ปัญหาที่หลายคนคิดกันมักไม่ตรงกับปัญหาจริง ในความเป็นจริงมันไม่ใช่ “แอสเซมบลีที่ไม่เหมาะสม” แต่เป็นระดับที่คาดหวังได้จาก C compiler มากกว่า ปัจจัยหลักมีดังนี้: มีทั้ง implementation แบบ C ทั่วไปของลูป และเวอร์ชัน asm/SIMD ที่เพิ่มเข้ามาตามฮาร์ดแวร์แต่ละแบบ แต่คุณลักษณะของ SIMD แตกต่างกันไปตามแพลตฟอร์มจนทำให้ทำให้เป็นนามธรรมได้ยาก ความต่างของเวอร์ชันคอมไพเลอร์อาจทำให้ผู้ใช้ทุกคนไม่ได้ใช้ implementation ที่ดีที่สุด memory model ของ C และการใช้ char * ขัดขวางการ optimization และบางครั้ง intrinsics กับความสามารถด้าน auto-vectorization ก็ชนกันเอง สำหรับ Intel C นั้น intrinsics บางทีกลับทำให้อ่านยากกว่า เพราะ Microsoft ตั้งชื่อฟังก์ชันไว้ซับซ้อนจนแอสเซมบลีกลับอ่านง่ายกว่า
    • ปกติก็ใช้เครื่องมืออย่าง vtune หรือ uprof เพื่อวิเคราะห์ benchmark hotspot ในระดับ ISA ส่วนเครื่องมือสำหรับ ARM ไม่ค่อยทราบ การให้คนเขียน intermediate representation อย่าง LLVM IR เองนั้นแทบไม่มีความหมายมากนัก ในกรณีส่วนใหญ่จะลงมือเขียนแอสเซมบลีเองเฉพาะกับปัญหาที่เป็นลักษณะเฉพาะของสถาปัตยกรรม C/C++ compiler โดยทั่วไปสร้างโค้ดที่ optimize ได้ดีอยู่แล้ว แต่โค้ดที่ถูก vectorize ต้องเปลี่ยนอัลกอริทึมตั้งแต่ต้น และเลี่ยงการใช้ intrinsics ไม่ได้ ซึ่งในกรณีนั้นโค้ดจะพกพาได้น้อยลงและหน้าตาคล้ายแอสเซมบลี อีกทั้งยังมี overhead จากโค้ดที่คอมไพเลอร์สร้างขึ้นมาอีก ดังนั้นจึงมักเขียนเป็นแอสเซมบลีไปเลย แล้วให้คนคอยดูเรื่อง register allocation หรือการจัดลำดับคำสั่งเองจะดีกว่า สุดท้ายแล้วแอสเซมบลีที่เขียนด้วยมือจะดีกว่าที่คอมไพเลอร์สร้างหรือไม่ ต้องวัดเท่านั้น benchmark จึงจำเป็นมาก
    • การเขียน LLVM IR โดยตรงไม่ค่อยมีประโยชน์ ถ้าจุดประสงค์คือโค้ดเวกเตอร์ ควรลอง vectorization pragmas ก่อน ถ้าไม่สำเร็จก็ค่อยใช้อินทรินสิกหรือภาษาอย่าง ISPC จะมีประสิทธิภาพกว่า ไม่มีประโยชน์อะไรที่ได้จาก IR แม้อยากแก้ปัญหาเรื่อง register allocation หรือ instruction selection ของคอมไพเลอร์ด้วยตัวเอง พอเขียนเป็น IR แล้วสุดท้ายคอมไพเลอร์ก็สร้างมันกลับเป็นโค้ดในแบบของมันอยู่ดี สรุปคือ IR ไม่เสถียรและแค่เพิ่มชั้นที่ใช้งานยากขึ้นมาเท่านั้น ถ้าจะทำแอสเซมบลีแบบเขียนมือที่ดีที่สุด ก็เขียนเป็นแอสเซมบลีไปตรงๆ เลยดีกว่า
  • น่าเสียดายที่ไม่ได้เริ่มจากบทนำง่ายๆ ที่ให้ลองลงมือกับ assembler จริงอย่าง NASM
  • คาดหวังว่าจะได้เห็นข้อมูลเชิงลึกหรือเคล็ดลับที่สั่งสมมาจากประสบการณ์มากมายของโปรเจ็กต์ แต่จากที่ดูเพียงไม่กี่บทกลับยังไม่ค่อยรู้สึกว่าเชื่อมโยงกับ ffmpeg โดยตรงนัก รู้สึกเหมือนเป็นเนื้อหาระดับเริ่มต้นเกี่ยวกับแอสเซมบลีทั่วๆ ไปมากกว่า
  • คิดว่าใน FFmpeg Assembly Lessons ถ้ารวมเอกสารบทเรียนคณิตศาสตร์ที่จำเป็นไว้ใน GitHub repository ด้วยก็น่าจะดี เพราะถ้ารวมทุกอย่างไว้ที่เดียวจะเริ่มต้นได้ง่ายกว่า
    • ไม่ใช่ผู้เขียน แต่ถ้าผู้อ่านมีแค่พื้นฐาน C programming และอยากมีส่วนร่วมกับ video codec จริงๆ ก็ยังมีความรู้พื้นหลังที่ต้องครอบคลุมอีกมากกว่าจะไปถึงเรื่องอย่างอัลกอริทึม Cooley-Tukey และนั่นก็ยังเป็นแค่พื้นฐานเท่านั้น
  • สงสัยว่าโค้ดแอสเซมบลีเหล่านี้ทำให้พกพาได้บน CPU หลากหลายแบบอย่างไร
    • คิดว่าโค้ดที่รันได้ด้วย C ทั่วไปน่าจะทำหน้าที่เป็น baseline และมีเวอร์ชันแอสเซมบลีที่เขียนมือแยกไว้ตามสถาปัตยกรรมหลัก
    • ในความเป็นจริงรองรับแค่ x86-64
  • อ่านแล้วน่าสนใจมาก รู้สึกว่าบทสอนที่เฉพาะโดเมนแบบนี้ดีกว่ามาก
  • มีส่วนที่ใช้ macro preprocessor ของ nasm หนักมากไปหน่อย ดูแล้วน่าจะย้ายไป assembler อื่นได้ยากพอสมควร
    • ก็สงสัยเหมือนกันว่าจำเป็นต้องย้ายไป assembler อื่นทำไม
    • อยากรู้ว่าเป็นส่วนไหน เพราะในโค้ดของบทเรียนจริงๆ แล้วแทบไม่มีโค้ดเลย