FFmpeg开发者通过手写汇编代码实现了显著性能提升，其中“rangedetect8_avx512”函数速度提升了100倍，但这一加速仅针对单一功能，而非整个FFmpeg应用。该功能此前未被优先优化，现通过SIMD技术大幅改进，现代处理器用户将体验到显著性能提升。

FFmpeg项目的开发者们再次展示了手写汇编代码在性能提升上的显著效果。最新补丁的应用使得这款跨平台开源媒体转码应用中的某个单一函数实现了“100倍的速度提升”。不过，开发者很快澄清，这一速度提升仅适用于特定函数，而非整个FFmpeg应用。

具体来说，最新的手写汇编补丁使‘rangedetect8avx512’函数的性能提升了100倍。如果用户的现代处理器不支持AVX512，使用rangedetect8avx2代码路径仍能获得64%的性能提升。开发者表示，这一速度提升主要体现在一个“较为冷门的滤镜”上，该滤镜的功能在某些系统上可能实现100%的速度提升。

由于该函数较为冷门，开发者此前并未优先优化它。但通过使用SIMD（单指令多数据）处理概念，开发者重新编写了该滤镜的代码，从而在现代强大的芯片上实现了显著的并行处理性能提升。

显然，编译器（将高级语言代码转换为汇编或机器代码的程序）在手写汇编面前仍不具备竞争力。正如FFmpeg在推特中所言，“编译器中的寄存器分配器表现不佳”。

回顾上世纪80年代和90年代的家用计算机黄金时代，固定规格系统的生命周期长达数年，且处理资源极为有限，手写汇编代码优化在加速计算机、游戏和其他软件方面发挥了重要作用。如今，FFmpeg或许是少数仍坚持“汇编福音”的项目之一，其开发团队甚至开设了“学校”来传授相关知识。

FFmpeg工具和库广泛应用于Linux、Mac OS X、Microsoft Windows、BSD、Solaris等系统。其中，最受欢迎的视频播放软件之一VLC就使用了FFmpeg项目中的libavcodec和libavformat库。

1. 对Pipewire和xdg桌面门户支持的期待

   • 评论1指出，ffmpeg CLI对Pipewire和xdg桌面门户的屏幕/窗口捕获支持进展缓慢，用户对此表示不满。
   • 引用："Still waiting for Pipewire + xdg desktop portal screen / window capture support in ffmpeg CLI. It's been dragging feet forever with it."
   • 中文："仍在等待ffmpeg CLI对Pipewire和xdg桌面门户的屏幕/窗口捕获支持。这件事已经拖延了很久。"

2. LLM在优化中的潜在作用

   • 评论2探讨了LLM（大语言模型）在优化中的潜力，认为虽然不应将其直接集成到编译器中，但未来可能会发生这种情况。
   • 引用："I wonder how many optimisations like this could be created by LLMs. Obviously we should not be incorporating LLMs into compilers, but I suspect that that's eventually what will happen."
   • 中文："我想知道LLM能创造出多少这样的优化。显然我们不应将LLM集成到编译器中，但我怀疑这最终会发生。"

3. 性能提升数据的混淆

   • 评论3指出文章中关于性能提升的数据存在混淆，100x和100%速度提升的含义完全不同，要求澄清。
   • 引用："The article sometimes says 100x, other times it says 100% speed boost. Which one is it?"
   • 中文："文章有时说100倍，有时说100%速度提升。到底是哪一个？"

4. x86架构的SIMD优化局限性

   • 评论4提到，尽管x86架构在过去十年中占据主导地位，但SIMD优化的扩展架构并不理想，且现在x86的普及性已不如从前。
   • 引用："Only for x86 / x86-64 architectures (AVX2 and AVX512). And now that you finally can use the new and better x86 SIMD, you can’t depend on x86 ubiquity anymore."
   • 中文："仅适用于x86 / x86-64架构（AVX2和AVX512）。现在你终于可以使用新的更好的x86 SIMD，但x86的普及性已不如从前。"

5. SIMD优化的实际效果与误导性

   • 评论5指出，SIMD优化的性能提升数据可能具有误导性，因为微基准测试与实际使用场景存在差异。
   • 引用："The devil is in the details, microbenchmarks are typically calling the same function a million times in a loop and everything gets cached reducing the overhead to sheer cpu cycles."
   • 中文："细节决定成败，微基准测试通常是在循环中调用同一函数一百万次，所有内容都被缓存，减少了开销，只剩下纯粹的CPU周期。"

6. Sound Open Firmware的类比

   • 评论6将文章内容与Sound Open Firmware（SOF）进行类比，指出SOF可以使用未优化的gcc或专有的Cadence XCC编译器进行编译。
   • 引用："Kind of reminds me of Sound Open Firmware (SOF), which can compile with either unoptimized gcc, or using the proprietary Cadence XCC compiler."
   • 中文："这让我想起了Sound Open Firmware（SOF），它可以使用未优化的gcc或专有的Cadence XCC编译器进行编译。"

7. 汇编语言与优化C语言的性能对比

   • 评论7表示惊讶，认为现代编译器已经非常优秀，手写汇编语言的性能提升应该微乎其微，但实际情况并非如此。
   • 引用："Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal."
   • 中文："实际上，听到汇编语言比优化C语言更快，我有点惊讶。我以为现代编译器已经非常优秀，手写汇编语言的性能提升应该微乎其微。"