FFmpeg開発者が手書きのアセンブリコードのおかげでさらに100倍の飛躍を誇る

2025年7月21日原文(tomshardware.com)

概要

FFmpegプロジェクト が手書きアセンブリで大幅な性能向上を実現
最新パッチで特定関数にて 100倍の高速化
性能向上は 特定のフィルター（rangedetect8_avx512） に限定
AVX512非対応CPUでも 64%の速度向上
手書きアセンブリの有効性と現代コンパイラの限界を示唆

FFmpeg、手書きアセンブリで100倍高速化

FFmpeg開発者 が手書きアセンブリによる 大幅なパフォーマンス向上 を発表
最新パッチ適用で、 rangedetect8_avx512関数 が 100倍高速化
この速度向上は FFmpeg全体 ではなく、「 単一関数」への適用であると開発者が強調
AVX512に非対応なCPU環境でも、 rangedetect8_avx2コードパス で 64%の速度向上
性能向上が体感できるのは、 一部の特殊なフィルター利用時 に限定

高速化の背景と技術的詳細

高速化された関数は 「rangedetect8_avx512」 という 比較的マイナーなフィルター
このフィルターはこれまで優先度が低く、最適化の対象外だった経緯
SIMD（ Single Instruction, Multiple Data）の活用で 並列処理性能 を最大化
現代の コンパイラによる最適化 では到達できないレベルのパフォーマンス
- 開発者は「 register allocator sucks on compilers」と指摘
手書きアセンブリは 1980～90年代のホームコンピュータ時代 を彷彿とさせる技術
- 当時は 限られたリソース を最大限活用するために必須の手法

FFmpegと関連プロジェクト

FFmpeg はLinux、Mac OS X、Microsoft Windows、BSD、Solarisなど 多様なOSで動作
VLC などの人気メディアプレイヤーも FFmpegのlibavcodecやlibavformat を利用
FFmpeg開発チーム はアセンブリの最適化手法を教える「 school」も運営
現在も数少ない「 アセンブリエバンジェリスト」としての存在感を発揮

今後の展望・まとめ

今回の 100倍高速化 はごく一部の関数に限定される
それでも 手書きアセンブリの有効性 と 現代コンパイラの課題 を再認識
今後も 特定用途での最適化 に期待
高度な最適化技術の継承と発展がFFmpegの強み

Hackerたちの意見

まだPipewireとxdgデスクトップポータルの画面/ウィンドウキャプチャサポートがffmpeg CLIに来るのを待ってる。ずっと足踏みしてる感じだね。

記事によっては100倍って言ったり、他のところでは100%のスピードブーストって言ったりしてる。例えば、「アプリの‘rangedetect8_avx512’のパフォーマンスを100.73%向上させる」って言ってるけど、スクリーンショットでは100.73倍って表示されてる。100倍だと9900%のスピードブーストになるし、100%のスピードブーストだと2倍速ってことになる。どっちなんだ？

└

ffmpegの人たちは100倍って言ってるみたいだね、100%じゃなくて。記事には多分誤植があるんじゃないかな。

└

単一の機能に対しては100倍、フィルター全体に対しては100%（2倍）ってことだね。

└

名前から判断すると、その関数は8ビットの値で動作してるんじゃないかな。もし前の実装がスカラーだったら、ダブルポンプのAVX512実装で128要素を同時に処理できるから、100倍のスピードアップはあり得るね。

└

スクリーンショットにある通り、確かに100倍（または100.73倍）だね。9973%のスピードアップを表してるけど、記事の中でパーセンテージの表記が間違ってるところがあるよ。

x86/x86-64アーキテクチャ専用（AVX2とAVX512）。10年以上もみんながx86を使ってたのに、理論的にはSIMD最適化が広範囲に及ぶはずだったのに、拡張アーキテクチャはかなりひどかった（新しいものが使えるとは限らなかった）。で、やっと新しくて良いx86 SIMDが使えるようになったのに、x86の普及に依存できなくなったのは皮肉だね。

└

AVX512は一連の拡張機能だよ。使いたいAVX512命令をすべて実装しているAVX512 CPUに頼ることはできないし、基本命令に絞らないとね。最近のエンコーダはスレッド間でのスケーリングも良くなってるけど、無限ではない。数年前に組み込みプロジェクトにいた時、SoCのビデオエンコーダを安定して動かすためにかなりの時間をかけたけど、誰かがffmpegを実行して、複数のCPUコアを使えばより良い結果が得られることに気づいたんだ。

HEVCのためにSIMD最適化を10年やってた時、アセンブリ版と普通のCを比べるのはちょっとしたジョークみたいだった。だって、100倍みたいなありえない倍率が出てくるから。実際には、最初から非常に非効率だったってことを意味してる。細かいところが肝心で、マイクロベンチマークは通常、同じ関数をループで百万回呼び出して、キャッシュが効いてオーバーヘッドがCPUサイクルだけになるけど、実際にはそんな使われ方はしない。たくさんの他の処理の中で一度呼ばれるかもしれない。少なくともキャッシュが熱くならないように大きなテスト領域を作ることはできるけど、彼らがそれをやるとは思えないな。

└

ちょっと脱線しちゃってごめんけど、SIMDの経験がめっちゃあるみたいだね。ISPC使ったことある？それについてどう思う？今の時代に手動でSIMDコードを書くのはちょっとおかしいと思う。普通のコンパイラは自動ベクトル化が下手だし、GPUカーネルではそんなことなかったのに。

└

ffmpegはマイクロベンチマークとそんなに変わらないよ。プログラム全体は基本的にこうだね：while (read(buf)) write(transform(buf))

└

それが本当に意味するのは、最初からすごく非効率だったってことだよ。僕は根本的な意味よりも結果の方が大事だから、それは当たり前だと思ってる。

Hacker Newsで議論の続きを見る

ハクソク