▲

FFmpeg 어셈블리 언어 레슨

 (github.com/FFmpeg)
2P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • FFmpeg 어셈블리 언어 레슨은 컴퓨터 내부 동작을 깊이 이해할 수 있도록 설계된 오픈소스 학습 자료임
  • 이 리포지토리는 FFmpeg에서 사용되는 어셈블리 언어의 실제 예시와 실습 중심 과제를 제공함
  • C 언어 포인터와 고등학교 수준의 수학 지식이 학습의 전제 조건임
  • 이를 통해 FFmpeg 오픈소스 프로젝트에 직접 기여할 능력을 배양할 수 있음
  • Discord 채널을 통해 질문 및 토론 지원이 제공됨

FFmpeg 어셈블리 언어 레슨 소개

  • FFmpeg School of Assembly Language는 프로그래밍에서 가장 흥미롭고 도전적이며 보람 있는 여정을 시작할 수 있도록 제작된 오픈소스 레슨임
  • 이 레슨을 통해 FFmpeg에서 어셈블리 언어가 어떻게 작성되는지를 실제 코드로 익히고, 컴퓨터 내부에서 어떤 일이 일어나고 있는지 체계적으로 이해할 수 있음

요구 지식

  • C 언어에 대한 이해, 특히 포인터 개념이 필수적임
    • C를 모를 경우에는 "The C Programming Language" 책을 먼저 공부할 필요가 있음
  • 고등학교 수준의 수학(스칼라와 벡터, 덧셈, 곱셈 등) 지식이 선행됨

레슨 구성 및 활용 방법

  • 본 GitHub 리포지토리에는 단계별 레슨과 각 레슨에 대응하는 과제가 포함되어 있음 (과제는 아직 업로드되지 않음)
  • 모든 과정을 이수하면 FFmpeg 프로젝트에 직접 기여할 수 있는 실전 역량을 갖추게 됨

커뮤니티 지원

다국어 번역

  • 프랑스어, 스페인어로도 레슨이 제공되고 있어 다양한 언어권 개발자들의 접근성이 높음
▲
GN⁺ 7일전  [-]
Hacker News 의견
  • FFMPEG의 규모를 상상하는 것만으로도 대단함을 느끼는 중임, 아주 작은 성능 향상이라도 수천, 수만 시간의 연산을 절약하는 효과가 있음, 정말 쓸모있는 프로젝트임
    • FFMPEG 팀의 성능에 대한 집념이 멋지다고 생각함, 모든 프로젝트가 저런 태도로 임한다면 얼마나 좋을까 상상함
    • 다만, 전통적인 의미의 확실한 API(명령형이 아니라 진짜 라이브러리 형태)가 있었으면 좋겠음, 지금처럼 자체 언어 같은 명령어 라인 파악하는 게 쉽지 않음
  • 이전 논의가 2025-02-22에 있었음, 222개의 댓글이 있음 이곳에서 확인 가능
  • 컴파일러가 생성한 비최적화 어셈블리 때문에 발생하는 핫스팟을 실제로 어떻게 찾아내는지 궁금함, 아키텍처별 어셈블리 대신 LLVM IR 같은 중간 표현을 직접 작성하는 게 의미가 있는지도 궁금함
    • 많은 사람들이 생각하는 문제들이 실제 이슈와 다름, 실제로는 “비최적화된 어셈블리”가 아니라 C 컴파일러로 기대할 수 있는 수준임, 주요 요인은 다음과 같음: 루프의 일반적인 C 구현과 하드웨어별로 추가되는 asm/SIMD 버전이 있음, 하지만 플랫폼마다 SIMD 특성이 달라서 일반화가 어려움, 컴파일러 버전 차이로 인해 모든 사용자가 최상의 구현을 활용하지 못할 수 있음, C의 메모리 모델과 char * 사용이 최적화를 방해함, 인트린식과 오토 벡터라이제이션 기능이 서로 충돌하기도 함, 인텔 C에서 인트린식은 Microsoft가 만든 복잡한 함수명 때문에 오히려 어셈블리가 더 읽기 쉬운 경우도 있음
    • 보통은 vtune이나 uprof 같은 툴로 ISA 레벨의 벤치마크 핫스팟을 분석함, ARM용 툴은 잘 모르겠음, LLVM IR 같은 중간 표현을 사람이 직접 작성하는 건 실제로 큰 의미가 없음, 대부분의 경우 아키텍처 특유의 문제에 대해서만 어셈블리를 직접 작성하게 됨, C/C++ 컴파일러가 일반적으로 최적화된 코드를 잘 생성하지만 벡터라이즈된 코드는 알고리즘 자체를 바꿔야 하고, 인트린식 사용이 불가피해지며 이 경우 코드가 이식성이 떨어지고 어셈블리처럼 보임, 게다가 컴파일러가 생성하는 코드 오버헤드가 있음, 그래서 그냥 어셈블리로 직접 작성하고 레지스터 할당이나 명령어 순서 등은 사람이 신경쓰는 게 나아짐, 결과적으로 핸드코딩 어셈블리가 컴파일러가 생성한 것보다 좋은지는 측정해봐야만 알 수 있음, 벤치마크가 꼭 필요함
    • LLVM IR을 직접 쓰는 건 별로 의미 없음, 벡터 코드를 위한 목적이라면 먼저 벡터화 지시문(pragmas)을 시도하고, 실패하면 인트린식이나 ISPC 같은 언어를 쓰는 게 효율적임, IR을 써서 얻는 이득이 없음, 컴파일러의 레지스터 할당이나 명령 선택 문제를 직접 해결하고 싶어도 IR로 작성하면 결국 컴파일러가 본래 코드로 다시 만들어버림, 결과적으로 IR은 불안정하고 사용이 더 어려운 계층만 추가할 뿐임, 가장 좋은 핸드코딩 어셈블리를 만들려면 그냥 어셈블리로 바로 작성하는 게 맞음
  • 아쉽게도 예제를 실제 NASM 같은 어셈블러로 실습하는 간단한 소개부터 시작하지 않는 점이 아쉬움
  • 프로젝트의 수많은 경험에서 우러나온 통찰이나 노하우를 기대했는데, 실제로 ffmpeg와 바로 연결되는 느낌은 잘 못 받겠음, 몇몇 챕터만 봤을 땐 그냥 일반적인 어셈블리 입문 수준의 내용처럼 느껴짐
  • FFmpeg Assembly Lessons에서 필요한 수학 강의 자료도 GitHub 저장소에 포함시키면 어떨까 생각함, 모든 자료가 한 자리에 모이면 시작하기 더 쉬울 것 같음
    • 작성자가 아니지만, 독자가 C 프로그래밍만 기본적으로 알고 있고 실제 비디오 코덱에 기여하고 싶다면, Cooley-Tukey 알고리즘 같은 내용에 도달하기까지 다뤄야 할 배경 지식이 상당히 많음, 그것도 기본적인 것에 불과함
  • 이 어셈블리 코드들이 다양한 CPU에서 어떻게 이식성을 확보하는지 궁금함
    • 내 생각엔 일반적인 C로 돌아가는 처리가 베이스라인 역할도 하며, 주요 아키텍처 별로는 직접 작성된 어셈블리 버전이 있음
    • 실제로는 x86-64만 대상임
  • 매우 흥미롭게 읽었음, 도메인 특화 튜토리얼이 훨씬 낫다고 느낌
  • nasm의 매크로 프리프로세서를 매우 남용한 부분이 있음, 다른 어셈블러로 옮기기가 상당히 어려워질 듯함
    • 굳이 왜 다른 어셈블러로 옮겨야 하는지 의문임
    • 어느 부분에서 그랬는지 궁금함, 수업 코드에선 실제로 코드가 거의 없음
답변달기