Posted on 07/17/2025 11:00:22 AM PDT by ShadowAce
The developers behind the FFmpeg project are again claiming major performance uplifts delivered by wielding the art of handwritten assembly code. With the latest patch applied, users should see a “100x speedup” in the cross-platform open-source media transcoding application. However, the developers were soon to clarify that the 100x claim applies to just a single function, “not the whole of FFmpeg.”
BREAKING: FFmpeg 100x speedup from handwritten assembly13:55:30 <•haasn> rangedetect8_avx512: 121.2 (100.18x) that may be the biggest speedup I've seen so farJuly 16, 2025
“The biggest speedup I've seen so far”
Last November, we reported on an FFmpeg performance boost that could speed certain operations by up to 94x. The latest handwritten assembly patch boosts the app’s ‘rangedetect8_avx512’ performance by 100.73%. If your modern processor doesn’t support AVX512, you should still see a 65.63% uplift with the rangedetect8_avx2 code path.
Where will you feel these speed increases? In some follow-up tweets, the FFmpeg developers admit that “It's a single function that's now 100x faster, not the whole of FFmpeg.” They would later go on to elaborate that the functionality, which might enjoy a 100% speed boost, depending upon your system, was “an obscure filter.”
The obscurity of the function means it hadn’t been prioritized by the devs until now. But we also gather that the filter code was recoded using the SIMD (Single Instruction, Multiple Data) processing concept for vastly improved parallel processing on today’s powerful chips.
Evidently, compilers – programs that take higher-level language code and spit out assembly (machine) code – are still not competitive with handwritten assembly. Or you could say, “register allocator sucks on compilers,” as FFmpeg tweeted today.
Assembly language evangelicals
Harking back to the golden age of home computing in the 1980s and 1990s, where fixed-spec systems had lifecycles measured in half-decades - and strictly limited processing resources - handwritten assembly code optimizations played a larger part in the business of speeding up computers, games, and other software.
FFmpeg is perhaps one of the few ‘assembly evangelists’ remaining. The dev team even runs a ‘school.’
FFmpeg tools and libraries run across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, systems, and more. One of the most popular video player software utilities, VLC, uses the libavcodec and libavformat libraries from the FFmpeg project.
I’ve been saying for years that the reason software eats up so much hardware (and it’s advances) is the compiler.
I did a bit of Assembly language programming, but it was not something I would have encouraged, then.
Today’s processors can do so much more on chip that it’s amazing. Assembly could likely help that, a lot.
(Instead of things designed to rip off and lay off humans.)
I became a COBOL programmer back in 1983. One of the arguments an old Assembler guy and I used to have was regarding “efficient” vs “easily maintainable” code. Even back in the 80’s computers had become so fast that we were more concerned about the cost of maintenance rather than the cost of processing.
I rewrote a batch “local long distance toll rating” program and reduced it from 10,500 lines to 5,600 lines. It even had “alter go tos” in it. In the process of rewriting it, I found four problems that, when the SME was notified, turned out were problems they were aware of, but had no idea which program was causing them.
Some sections were accessed through “go to” and were accessed from other sections via “perform”, and sometimes “perform through”. It was a mess.
I had been trained by Boeing in “Pretty code”. It mattered. This was in 1993. I’m shocked I still remember this while I can’t remember where I laid down my phone.
Inquiring mind wants to know. ;-)
On and Offenbach, and all that.
But improvements to compilers should be the priority. It does not seem to be that way these days.
.
Hand written? So some people can still read cursive?
The first program I bought was a machine language monitor and it was 110 bytes of code. Ran on a computer with 4k of memory. That code was tight and elegant and puts todays bloated software to shame.
But then again--I'm ancient.
Well I learned cursive when home schooled.
COBOL and Assembler.......I learned IBM 360 versions of both in college in the ‘70’s, and served an internship at Columbia River Log Scaling Bureau in Eugene, Or. The main thing I learned from the internship was that programming was just a hobby for me, not a career.
I only use Windowz PC, but the computer bargain on the year is the M4 mac-mini at $549. That has 256GB NVMe and 16GB RAM. During Prime Days last week it was only $500. If I bought one, the only thing I would add would be 1TB external NVMe for storage. Price about 70-80$
DisplayPort is the way to go and this mac-mini can run three displays simultaneously VIA>>>
Thunderbolt 4 (USB-C) ports (located on the back)
One HDMI 2.1 port
Yeah l dabbled in assy too. When every byte of memory was precious it was a go to tool.
Interesting- a program I was working at BA used Python and Jinja to create templates for C++ modules.
We did a lot macro’s for BASM. It helped a little bit, also subroutines were helpful but not near as neat as functions in ‘C’. Having to save and restore registers was always the biggest issue.
Yeah l dabbled in assy too. When every byte of memory was precious it was a go to tool.
In my experience. going back into old code to "make it pretty" is often how that kind of problem is found and corrected.
Some sections were accessed through “go to” and were accessed from other sections via “perform”, and sometimes “perform through”. It was a mess.
Sounds like a true coding abomination. Congratulations on sorting out such a thing. A lesser talent might have run screaming for the door with their hair on fire.
How long did it take before the nightmares stopped?
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.