I'm halfway through this tutorial and I'm really enjoying it. I haven't touched assembly since back in university decades ago. I've always had an urge to optimize processes for some reason. This scratches that itch. I was also more curious about SIMD since hearing about it on Digital Foundry.
FFmpeg School of Assembly Language
61–70 of 226 posts
Re: FFmpeg School of Assembly Language
#62I personally don't think there's much value in writing assembly (vs using intrinsics), but it's been really helpful to read it. I have often used Compiler Explorer (https://godbolt.org/) to look at the assembly generated and understand optimizations that compilers perform when optimizing for performance.
Re: FFmpeg School of Assembly Language
#63This os a great article!
Re: FFmpeg School of Assembly Language
#64I'm curious from anyone who has done it. Is there any "pleasure" to be had in learning or implementing assembly (like there is for LISP or RISC-V) or is it something you learn and implement because you want to do something else (like learning COBOL if you need to work with certain kinds of systems). It has always piqued my interest but I don't have a good reason in my day-to-day job to get into it. Wondering if it is…
It was cool back in the day, when the alternative was BASIC, also during the demoscene early days.
Nowadays most of that can be done with intrinsics, which were already present in some 1960's system programming languages, predating UNIX for a decade.
Modern Assembly is too complex, it is probably easier to target retrogaming, or virtual consoles, if the purpose is having fun.
Re: FFmpeg School of Assembly Language
#65I'm curious from anyone who has done it. Is there any "pleasure" to be had in learning or implementing assembly (like there is for LISP or RISC-V) or is it something you learn and implement because you want to do something else (like learning COBOL if you need to work with certain kinds of systems). It has always piqued my interest but I don't have a good reason in my day-to-day job to get into it. Wondering if it is…
If you want to get the ultimate performance out of a processor, understanding assembly is paramount. Writing it by hand is less critical today than it was in the days of old 8- and 16-bit CPUs when memory was at a premium, instruction cycle counts were known constants, and sequential execution was guaranteed. But being able to read your compiler's output and understand what the optimizer does is a huge performance win.
Re: FFmpeg School of Assembly Language
#66Earlier quoted context omitted.
Probably some very niche things. I know I can't write ASM that's 10x better than C, but I wouldn't assume no one can.
It depends on what you're trying to do. I would in general only expect such substantial speedups when considering writing computation kernels (for audio, video, etc). Compilers today are liable in most circumstances to know many more tricks than you do. Especially if you make use of hints (e.g. "this memory is almost always accessed sequentially", "this branch is almost never taken", etc) to guide it.
Oh I definitely agree that in the vast majority of cases the compiler will probably win.
But I suspect there are cases where the super experts exist who can do things better.
Re: FFmpeg School of Assembly Language
#67Asm is 10x faster than C? That was definitely true at some point but is it still true today? Have compilers really stagnated so badly they can't come close to hand coded asm?
I remember a series of lectures from an Intel engineer that went into how difficult it was writing assembly code for x86. He basically stated that the number of cases you can really write code that is faster than what a compiler would do is close to none. Essentially people think they are writing low level code, in reality that's not how CPUs interpret that code, so he explained how writing manual assembly kills perf…
You have to consider that modern CPUs don't execute code in-order, but speculatively, in multiple instruction pipelines.
I've used Intel's icc compiler and profiler tools in an iterative fashion. A compiler like Intel's might be made to profile cache misses, pipeline utilization, branches, stalls, and supposedly improve in the next compilation.
The assembly programmer has to consider those factors. Sure would be nice to have a computer check those things!
In the old days, we only worried about cycle counts, wait states, and number of instructions.
Re: FFmpeg School of Assembly Language
#68I'm curious from anyone who has done it. Is there any "pleasure" to be had in learning or implementing assembly (like there is for LISP or RISC-V) or is it something you learn and implement because you want to do something else (like learning COBOL if you need to work with certain kinds of systems). It has always piqued my interest but I don't have a good reason in my day-to-day job to get into it. Wondering if it is…
I took a course in it in college. Extreme fun. Currently, python microservices don't have much need of this exact skill, but it gave me a significant confidence bust at the time that I actually know what is going on.
Re: FFmpeg School of Assembly Language
#69Earlier quoted context omitted.
"The FFmpeg devs are somewhat infamously against intrinsics (they don't allow them in their codebase even if the performance is as good as equivalent assembly)" Why?
Did you read lesson one? TL;DR They want to squeeze every drop of performance out of the CPU when processing media, and maintaining a mixture of intrinsics code and assembly is not worth the trade off when doing 100% assembly offers better performance guarantees, readability, and ease of maintenance / onboarding of developers.
Well that was more true when you had to care about the 8 registers of x86, CPUs were only like 2-4 wide, and codecs preferred to operate on 8x8 blocks and one bitdepth.
Nowadays the impact of suboptimal register allocation and addressing calculations of compilers is almost unmeasurable between having 16/32 registers available and CPUs that are 8-10 wide in the frontend but only 3-4 vector units in the backend. But the added complexity of newer codecs has strained their use of the nasm/gas macro systems to be far less readable or maintainable than intrinsics. Like, think of how unmaintainable complex C macros are and double that.
And it's not uncommon to find asm in ffmpeg or related projects written suboptimally in a way a compiler wouldn't, either because the author didn't fully read/understand CPU performance manuals or because rewriting/twisting the existing macros to fix a small suboptimality is more work than it's worth.
(yes, I have written some asm for ffmpeg in the past)
Re: FFmpeg School of Assembly Language
#70Earlier quoted context omitted.
You're not wrong but that's more of an issue with C than an issue with intrinsics, in higher level languages like C++ or Rust you have the option to wrap instrinsics in types which are much nicer to work with.
>C++ or Rust Nah. I find well commented three column AT&T assembly with light use of C preprocessor macros easier and more enjoyable to read.
Now that's what I call an unpopular opinion.