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 リポジトリには、段階別のレッスンと各レッスンに対応する課題が含まれている（課題はまだアップロードされていない）
  • すべての過程を修了すると、FFmpeg プロジェクトに直接貢献できる実践力を身につけられる

コミュニティサポート

多言語翻訳

  • フランス語、スペイン語でもレッスンが提供されており、さまざまな言語圏の開発者にとってアクセスしやすい

関連記事

1件のコメント

 
GN⁺ 2025-08-19
Hacker Newsの意見
  • FFMPEGの規模を想像するだけでもすごいと感じる。ほんのわずかな性能向上でも、数千、数万時間分の計算を節約する効果がある。本当に有用なプロジェクトだ
    • FFMPEGチームの性能への執念は見事だと思う。すべてのプロジェクトがあのような姿勢で取り組んでくれたらどれほどいいだろうかと想像する
    • ただ、伝統的な意味での明確なAPI（命令型ではなく、本当のライブラリ形式）があってほしい。今のように独自言語のようなコマンドラインを読み解くのは簡単ではない
  • 前回の議論は2025-02-22にあり、222件のコメントがある。ここで確認できる
  • コンパイラが生成した非最適なアセンブリによって生じるホットスポットを、実際にどうやって見つけるのか気になる。アーキテクチャごとのアセンブリの代わりに、LLVM IRのような中間表現を直接書くことに意味があるのかも気になる
    • 多くの人が考える問題は、実際の課題とは異なる。実際には「非最適なアセンブリ」ではなく、Cコンパイラに期待できる水準の話だ。主な要因は次の通り。ループの一般的なC実装と、ハードウェアごとに追加されるasm/SIMD版があるが、プラットフォームごとにSIMD特性が異なるため一般化が難しい。コンパイラのバージョン差によって、すべてのユーザーが最良の実装を使えるとは限らない。Cのメモリモデルと char * の使用が最適化を妨げる。イントリンシックと自動ベクトル化機能が衝突することもある。Intel 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のマクロプリプロセッサをかなり乱用している部分があり、他のアセンブラへ移植するのは相当難しくなりそうだ
    • そもそも、なぜわざわざ他のアセンブラへ移植する必要があるのか疑問だ
    • どの部分でそうなっているのか気になる。授業用コードには実際ほとんどコードがない