I can’t imagine the scale that FFMPEG operates at. A small improvement has to be thousands and thousands of hours of compute saved. Insanely useful project.
There's tons of backlash here as if people think better performance requires writing in assembly.
But to anyone complaining, I want to know, when was the last you pulled out a profiler? When was the last time you saw anyone use a profiler?
People asking for performance aren't pissed you didn't write Microsoft Word in assembly we're pissed it takes 10 seconds to open a fucking text editor.
I literally timed it on my M2 Air. 8s to open and another 1s to get a blank document. Meanwhile it took (neo)vim 0.1s and it's so fast I can't click my stopwatch fast enough to properly time it. And I'm not going to bother checking because the race isn't even close.
I'm (we're) not pissed that the code isn't optional, I'm pissed because it's slower than dialup. So take that Knuth quote you love about optimization and do what he actually suggested. Grab a fucking profiler, it is more important than your Big O
Another datapoint that supports your argument is the Grand Theft Auto Online (GTAO) thing a few months ago.[0] GTAO took 5-15 minutes to start up. Like you click the icon and 5-15 minutes later you're in the main menu. Everyone was complaining about it for years. Years. Eventually some enterprising hacker disassembled the binary and profiled it. 95% of the runtime was in `strlen()` calls. Not only was that where all the time was spent, but it was all spent `strlen()`ing the exact same ~10MB resource string. They knew exactly how large the string was because they allocated memory for it, and then read the file off the disk into that memory. Then they were tokenizing it in a loop. But their tokenization routine didn't track how big the string was, or where the end of it was, so for each token it popped off the beginning, it had to `strlen()` the entire resource file.
The enterprising hacker then wrote a simple binary patch that reduced the startup time from 5-10 minutes to like 15 seconds or something.
To me that's profound. It implies that not only was management not concerned about the start up time, but none of the developers of the project ever used a profiler. You could just glance at a flamegraph of it, see that it was a single enormous plateau of a function that should honestly be pretty fast, and anyone with an ounce of curiousity would be like, ".........wait a minute, that's weird." And then the bug would be fixed in less time than it would take to convince management that it was worth prioritizing.
It disturbs me to think that this is the kind of world we live in. Where people lack such basic curiosity. The problem wasn't that optimization was hard, (optimization can be extremely hard) it was just because nobody gave a shit and nobody was even remotely curious about bad performance. They just accepted bad performance as if that's just the way the world is.
I just started getting back into gaming and I'm seeing shit like this all the time. It's amazing that stuff like this is so common while the Quake fast inverse square root algo is so well known.
How is it that these companies spend millions of dollars to develop games and yet modders are making patches in a few hours fixing bugs that never get merged. Not some indie game, but AAA rated games!
I think you're right, it's on both management and the programmers. Management only knows how to rush but not what to rush. The programmers fall for the trap (afraid to push back) and never pull up a profiler. Maybe over worked and over stressed but those problems never get solved if no one speaks up and everyone is quiet and buys into the rush for rushing's sake mentality.
It's amazing how many problems could be avoided by pulling up a profiler or analysis tool (like Valgrind).
It's amazing how many millions of dollars are lost because no one ever used a profiler or analysis tool.
I'll never understand how their love for money makes them waste so much of it.
AAA games are, largely, quite bad in quality these days. Unfortunately, the desire to make a quality product (from the people who actually make the games) is overruled by the desire to maximize profit (from the people who pay their salaries). Indie games are still great, but I barely even bother to glance at AAA stuff any more.
That has been like that since there have been publishers in the games industry.
Back then, the indies stuff was only if you happened to live nearby someone you knew doing bedroom coding, distributing tapes on school, or they got lucky land their game on one of those shareware tapes collection.
Trying to actually get a publisher deal was really painful, and if you did, they really wanted their money back in sales.
I'm just wondering if/when anyone will realize that often desire gets in the way of achieving. ̶T̶h̶e̶y̶ ̶m̶a̶y̶ ̶b̶e̶ ̶p̶e̶n̶n̶y̶ ̶w̶i̶s̶e̶ ̶b̶u̶t̶ ̶t̶h̶e̶y̶'̶r̶e̶ ̶p̶o̶u̶n̶d̶ ̶f̶o̶o̶l̶i̶s̶h̶.̶ Chasing pennies with dollars
iirc this bug existed from release but didn't impact the game until years later after a sizable number of DLCs were added to the online mode, since the function only got slower with each one added. Not that it's fine that the bug stayed in that long, but you can see how it would be missed given that when they had actual programmers running profilers at development time it wouldn't have raised any red flags after completing in ten seconds or whatever.
I don't know. As a developer there would be even more reason to be curious as to why the release binary is an order of magnitude slower then what is seen in development.
> To me that's profound. It implies that not only was management not concerned about the start up time, but none of the developers of the project ever used a profiler.
Odds are that someone did notice it during profiling and filed a ticket with the relevant team to have it fixed, which was then set to low priority because implementing the latest batch of microtransactions was more important.
I feel like this is just a natural consequence of the metrics-driven development that is so prevalent in large businesses nowadays. Management has the numbers showing them how much money they make every time they add a new microtransaction, but they don't have numbers showing them how much money they're losing due to people getting tired of waiting 15 minutes for the game to load, so the latter is simply not acknowledged as a problem.
Your computer is broken. My M1 Pro launches it to user interactive in less than two seconds. And, to be clear, I launched it in a profiler. I suggest you do the same on your machine and find out why it's taking that long.
> People asking for performance aren't pissed you didn't write Microsoft Word in assembly we're pissed it takes 10 seconds to open a fucking text editor.
It could be worse I suppose...
Some versions of Microsoft Excel had a flight simulator embedded in them[0]!
I mean we're talking about a fucking text editor here. A second to load is a long time even if it was on an intel i3 from 10 years ago. Because... it is a text editor... Plugins and all the fancy stuff is nice, but those can be loaded asynchronously and do not need to prevent you from jumping into a blank document.
But the god damn program is over 2GB in size... like what the fuck... There's no reason for an app I open a few times a year and have zero plugins and ONLY does text editing should even be a gig.
Seriously, get some context before you act high and mighty.
I don't know how anyone can look at Word and think it is anything but the accumulation of bloat and tech debt piling up. With decades of "it's good enough" compounding and shifting the bar lower as time goes on.
As an industry we are too bad at correctness to even begin to worry about performance. Looking at FFmpeg (who are a pretty good project that I don't want to pick on too much) I see their most recent patch release fixes 3 CVEs from 2023 plus one from this year, and that's just security vulnerabilities, never mind regular bugs. Imagine if half the effort that people put into making it fast went into making it right.
That would be an enormous waste of time. 99.9% of software doesn't have to be anywhere near optimal. It just has to not be wasteful.
Sadly lots of software is blatantly wasteful. But it doesn't take fancy assembly micro optimization to fix it, the problem is typically much higher level than that. It's more like serialized network requests, unnecessarily high time complexities, just lots of unnecessary work and unnecessary waiting.
Once you have that stuff solved you can start looking at lower level optimization, but by that point most apps are already nice and snappy so there's no reason to optimize further.
Sorry, I would word it differently. 99.9% software should be decently performant. Yes, don't need 'fancy assembly micro optimization'. That said, today some large portion of software is written by folks who absolutely doesn't care about performance - just duct-taping some sh*t to somehow make it work and call it a day.
Hard disagree. I'd like word processors to not need ten seconds just to start up. I'd like chat clients not to use _seconds_ to echo my message back to me. I'd like news pages that don't empty my mobile data cap just by existing. All of these are “non-performance critical”, but I'd _love_ for them to focus on performance.
Many things are slow because few programmers (or managers) care. Because they'll argue about "value" but all those notions of value are made up anyways.
People argue "sure, it's not optimal, but it's good enough". But that compounds. A little slower each time. A little slower each application. You test on your VM only running your program.
But all of this forgets what makes software so powerful AND profitable: scale. Since we always need to talk monetary value, let's do that. Shaving off a second isn't much if it's one person or one time but even with a thousand users that's over 15 minutes, per usage. I mean we're talking about a world where American Airlines talks about saving $40k/yr by removing an olive and we don't want to provide that same, or more(!), value to our customers? Let's say your employee costs $100k/yr and they use that program once a day. That's 260 seconds or just under 5 minutes. Nothing, right? A measly $4. But say you have a million users. Now that's $4 million!
Now, play a fun game with me. Just go about your day as normal but pay attention to all those little speedbumps. Count them as $1m/s and let me know what you got. We're being pretty conservative here as your employee costs a lot more than their salary (2-3x) and we're ignoring slowdown being disruptive and breaking flow. But I'm willing to bet in a typical day you'll get on the order of hundreds of millions ($100m is <2 minutes).
We solve big problems by breaking them into a bunch of smaller problems, so don't forget that those small problems add up. It's true even if you don't know what big problem you're solving.
untrue. what bloats the modern web is the widespread AND suboptimal use of web frameworks. otherwise, making adblockers would dramatically speed up the loading of every website that uses ads, while it is true to some extent, is not the entire picture. anyways, i'm not saying that these libraries are always slow, but the users aren't aware of the performance characteristics and perf habits they should use while making use of such libraries. do you have any idea how many tens of layers of abstractions a "website" takes to reach your screen?
So you’re a PM for a word processor. You have a giant backlog.
Users want to load and edit PDFs. Finnish has been rendering right to left for months, but the easy fix will break Hebrew. The engineers say a new rendering engine is critical or these things will just get worse. Sales team says they’re blocked on a significant contract because the version tracking system allows unaudited “clear history” operations. Reddit is going berserk because the icon you used (and paid for!) for the new “illuminated text mode” turns out to be stolen from a Lithuanian sports team.
Knowing that most of your users only start the app when their OS forces a reboot… just how much priority does startup time get?
This is an incredibly convoluted hypothetical trying to negate the idea that users notice and/or appreciate how quickly their applications start. Usually as a PM you are managing multiple engineers, one of which I would assume is capable of debugging and eventually implementing a fix for faster start times. Even if they can't fix it immediately due to whatever contrived reason you've supposed, at least they will know where and how to fix it when the time does come. In fact, I would argue pretending there is no issue because of your mountain of other problems is the worst possible scenario to be in.
I don't think that fits MS Office. The situation is more that you have a working, usable word processor which has all the festures your user needs. Since many years ago. But your UI designer thinks it can be a little more beautiful but much slower. Of course you give that way too much priority.
On my Laptop where I am forced by my company to run windows, I run word 2010 and it runs far better(speed and stability) that the newest word I have to use ob my office pc.
Many of the important decisions are made at design and review time. When that team adds PDF support, they should act unlike the Explorer team and avoid unnecessary O(n^2) algorithms.
Part of getting this to happen is setting the right culture and incentives. PM is such a nebulous term that I can't say this definitively, but I don't think the responsibility for this lies with them. Some poor performance is simply tech debt and should be tackled in the same way.
$WORD_PROCESSOR employees should be capable of this: we've all seen how they interview.
When I was in school I had a laundry app (forced to use) that took 8 seconds to load, mostly while it scanned the network for the machines. It also had the rooms out of order in the room listing and no caching so every time you wanted to check the status (assuming it even worked) it took no less than a minute. It usually took less time to physically check, which also had a 100% accuracy.
Fuck this "we don't need to optimize" bullshit. Fuck this "minimum viable product" bullshit. It's just a race to the bottom. No one paper cut is the cause of death, but all of them are when you have a thousand.
On this machine it took me about 8 seconds to get the start menu open, about 5 seconds to get it to recognize that I'd typed "calc", another 5 seconds for it to let me actually select it to launch, and then about 20 seconds from the calculator window appearing - in its empty loading state - for it to actually come up. I admit this computer is several years old - but ... it's... a calculator.
On Windows 11 I can see a startup screen briefly before it loads the calculator buttons -- takes maybe 2 seconds all up -- seems to be 1 seconds to start up screen then another second to populate the buttons. But can understand why people feel it's a regression though as I reall the win95/98/me calc.exe would pretty much appear near instantly even on the CPU/RAM/etc of the day.
I'm currently on a Windows 10 machine with Core i5 that's more than a decade old. The calculator takes a couple of seconds to start up - provided it's a "good" day (i.e. one when Windows isn't downloading updates or doing search indexing or malware scanning in the background.)
But I also have a Core 2 Duo-based WinXP machine in easy reach (just to keep a legacy software environment alive) and its keyboard has a dedicated calculator button. The calculator is just there the moment I press that button - it's appeared long before I can even release the button.
Indeed. All else remaining the same, a faster program is generally more desirable than a slower program, but we don't live in generalities where all else remains the same and we simply need to choose fast over slow. Fast often costs more to produce.
Programming is a small piece of a larger context. What makes a program "good" is not a property of the program itself, but measured by external ends and constraints. This is true of all technology. Some of these constraints are resources, and one of these resources is time. In fact, the very same limitation on time that motivates the prioritization of development effort toward some features other than performance is the very same limitation that motivates the desire for performance in the first place.
Performance must be understood globally. Let's say we need a result in three days, and it takes two days to write a program that takes one day to get the result, but a week to write a program that takes a second to produce a result, then obviously, it is better to write the program the first way. In a week's time, your fast program will no longer be needed! The value of the result will have expired.
Seems so easy! You only need the entire world even tangentially related to video to rely solely on your project for a task and you too can have all the developers you need to work on performance!
ffmpeg has competition. For the longest time it wasn't the best audio encoder for any codec[0], and it wasn't the fastest H.264 decoder when everyone wanted that because a closed-source codec named CoreAVC was better[1].
ffmpeg was however, always the best open-source project, basically because it had all the smart developers who were capable of collaborating on anything. Its competition either wasn't smart enough and got lost in useless architecture-astronauting[2], or were too contrarian and refused to believe their encoder quality could get better because they designed it based on artificial PSNR benchmarks instead of actually watching the output.
[0] For complicated reasons I don't fully understand myself, audio encoders don't get quality improvements by sharing code or developers the way decoders do. Basically because they use something called "psychoacoustic models" which are always designed for the specific codec instead of generalized. It might just be that noone's invented a way to do it yet.
[1] I eventually fixed this by writing a new multithreading system, but it took me ~2 years of working off summer of code grants, because this was before there was much commercial interest in it.
[2] This seems to happen whenever I see anyone try to write anything in C++. They just spend all day figuring out how to connect things to other things and never write the part that does anything?
> They just spend all day figuring out how to connect things to other things and never write the part that does anything?
I see a lot of people write software like this regardless of language. Like their job is to glue pieces of code together from stack overflow. Spending more time looking for the right code that kinda sorta works than it would take to write the code which will just work.
I was thinking about two types of people; one gets distracted and starts writing their own UI framework and standard library and never gets back to the program. The other starts writing a super-flexible plugin system for everything because they're overly concerned with developing a community to the point they don't want to actually implement anything themselves.
(In this space the first was a few different mplayer forks and the second was gstreamer.)
Sometimes they get there but a lot of times not too.
I'm pretty sure there are a lot more types and the two you wrote aren't the copy-pasters either. Me, I try to follow the Unix philosophy[0] though I think there's plenty of exceptions to be made. Basically just write a bunch of functions and make your functions simple. Function overhead calls are usually cheap so this allows things to be very flexible. Because the biggest lesson I've learned is that the software is going to change so it is best to write with this in mind. The best laid plans of mice and men and all I guess. So write for today but don't forget about tomorrow.
Then of course there are those that love abstractions, those that optimize needlessly, and many others. But I do feel the copy-pasters are the most common type these days.
No one is forcing them to produce code for free. There is something toxic about giving things away for free with the ulterior motive of getting money for it.
It’s market manipulation, with the understanding that free beats every other metric.
Once the competition fails, the value extraction process can begin. This is where the toxicity of our city begins to manifest. Once there is no competition remaining we can begin eating seeds as a pastime activity.
The toxicity of our city; our city. How do you own the world? Disorder.
You know friend, if open source actually worked like that I wouldn’t be so allergic to releasing projects. But it doesn’t - a large swath of the economy depends on unpaid labour being treated poorly by people who won’t or can’t contribute.
It'd be nice, though, to have a proper API (in the traditional sense, not SaaS) instead of having to figure out these command lines in what's practically its own programming language....
FFMpeg does have an API. It ships a few libraries (libavcodec, libavformat, and others) which expose a C api that is used in the ffmpeg command line tool.
They're relatively low level APIs. Great if you're a C developer, but for most things you'd do in python just calling the command line probably does make more sense.
As someone that used these APIs in C, they were not very well-documented nor intuitive, and oftentimes segfaulted when you messed up, instead of returning errors—I suppose the validation checks sacrifice performance for correctness, which is undesirable. Either way, dealing with this is not fun. Such is the life of a C developer, I suppose....
Yes, that's what I did some time ago. I already want concurrency and isolation, so why not let the OS do that. Also I don't need to manage resources, when ffmpeg already does that.
If you are processing user data, the subprocess approach makes it easier to handle bogus or corrupt data. If something is off, you can just kill the subprocess. If something is wrong with the linked C api, it can be harder to handle predictably.
I get why the CLI is so complicated, but I will say AI has been great at figuring out what I need to run given an English language input. It's been one of the highest value uses of AI for me.
I would be interested in more examples where "assembly is faster than intrinsics". I.e., when the compiler screws up. I generally write Zig code with the expectation of a specific sequence of instructions being emitted, and I usually get it via the high level wrappers in std.simd + a few llvm intrinsics. If those fail I'll use inline assembly to force a particular instruction. On extremely rare occasions I'll rely on auto-vectorization, if it's good and I want it to fall back on scalar on less sophisticated CPU targets (although sometimes it's the compiler that lacks sophistication). Aside from the glaring holes in the VPTERNLOG finder, I feel that instruction selection is generally good enough that I can get whatever I want.
The bigger issue is instruction ordering and register allocation. On code where the compiler effectively has to lower serially-dependent small snippets independently, I think the compiler does a great job. However, when it comes to massive amounts of open code I'm shocked at how silly the decisions are that the compiler makes. I see super trivial optimizations available at a glance. Things like spilling x and y to memory, just so it can read them both in to do an AND, and spill it again. Constant re-use is unfortunately super easy to break: Often just changing the type in the IR makes it look different to the compiler. It also seems unable to merge partially poisoned (undefined) constants with other constants that are the same in all the defined portions. Even when you write the code in such a way where you use the same constant twice to get around the issue, it will give you two separate constants instead.
I hope we can fix these sorts of things in compilers. This is just my experience. Let me know if I left anything out.
>There are two flavours of x86 assembly syntax that you’ll see online: AT&T and Intel. AT&T Syntax is older and harder to read compared to Intel syntax. So we will use Intel syntax.
So the main issues here are not what people think they are. They generally aren't "suboptimal assembly", at least not what you can reasonably expect out of a C compiler.
The factors are something like:
- specialization: there's already a decent plain-C implementation of the loop, asm/SIMD versions are added on for specific hardware platforms. And different platforms have different SIMD features, so it's hard to generalize them.
- predictability: users have different compiler versions, so even if there is a good one out there not everyone is going to use it.
- optimization difficulties: C's memory model specifically makes optimization difficult here because video is `char *` and `char *` aliases everything. Also, the two kinds of features compilers add for this (intrinsics and autovectorization) can fight each other and make things worse than nothing.
- taste: you could imagine a better portable language for writing SIMD in, but C isn't it. And on Intel C with intrinsics definitely isn't it, because their stuff was invented by Microsoft, who were famous for having absolutely no aesthetic taste in anything. The assembly is /more/ readable than C would be because it'd all be function calls with names like `_mm_movemask_epi8`.
One time I spent a week carefully rewriting all of the SIMD asm in libtheora, really pulling out all of the stops to go after every last cycle [0], and managed to squeeze out 1% faster total decoder performance. Then I spent a day reorganizing some structs in the C code and got 7%. I think about that a lot when I decide what optimizations to go after.
Unfortunately modern processors do not work how most people think they do. Optimizing for less work for a nebulous idea of what "work" is generally loses to bad memory access patterns or just using better instructions that seem most expensive if you look at them superficially.
> And on Intel C with intrinsics definitely isn't it, because their stuff was invented by Microsoft, who were famous for having absolutely no aesthetic taste in anything.
Wouldn't Intel be the one defining the intrinsics? They're referenced from the ISA manuals, and the Intel Intrinsics Guide regularly references intrinsics like _allow_cpu_features() that are only supported by the Intel compiler and aren't implemented in MSVC.
Uh, no, that's standard practice for disambiguating the intrinsic operations for different data types without overloading support. ARM does the same thing with their vector intrinsics, such as vaddq_u8(), vaddq_s16(), etc.
Normally you spin up a tool like vtune or uprof to analyze your benchmark hotspots at the ISA level. No idea about tools like that for ARM.
> Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
IME, not really. I've done a fair bit of hand-written assembly and it exclusively comes up when dealing with architecture-specific problems - for everything else you can just write C (unless you hit one of the edge cases where C semantics don't allow you to express something in C, but those are rare).
For example: C and C++ compilers are really, really good at writing optimized code in general. Where they tend to be worse are things like vectorized code which requires you to redesign algorithms such that they can use fast vector instructions, and even then, you'll have to resort to compiler intrinsics to use the instructions at all, and even then, compiler intrinsics can lead to some bad codegen. So your code winds up being non-portable, looks like assembly, and has some overhead just because of what the compiler emits (and can't optimize). So you wind up just writing it in asm anyway, and get smarter about things the compiler worries about like register allocation and out-of-order instructions.
But the real problem once you get into this domain is that you simply cannot tell at a glance whether hand written assembly is "better" (insert your metric for "better here) than what the compiler emits. You must measure and benchmark, and those benchmarks have to be meaningful.
Hit enter on the symbol, and you get instruction-level profiles. Or use perf annotate explicitly. (The profiles are inherently instruction-level, but the default perf report view aggregates them into function-level for ease of viewing.)
> Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
Not really. There are a couple of reasons to reach for handwritten assembly, and in every case, IR is just not the right choice:
If your goal is to ensure vector code, your first choice is to try slapping explicit vectorize-me pragmas onto the loop. If that fails, your next effort is either to use generic or arch-specific vector intrinsics (or jump to something like ISPC, a language for writing SIMT-like vector code). You don't really gain anything in this use case from jumping to IR, since the intrinsics will satisfy your code.
If your goal is to work around compiler suboptimality in register allocation or instruction selection... well, trying to write it in IR gives the compiler a very high likelihood of simply recanonicalizing the exact sequence you wrote to the same sequence the original code would have produced for no actual difference in code. Compiler IR doesn't add anything to the code; it just creates an extra layer that uses an unstable and harder-to-use interface for writing code. To produce the best handwritten version of assembly in these cases, you have to go straight to writing the assembly you wanted anyways.
Loop vectorization doesn't work for ffmpeg's needs because the kernels are too small and specialized. It works better for scientific/numeric computing.
You could invent a DSL for writing the kernels in… but they did, it's x86inc.asm. I agree ispc is close to something that could work.
Why not include the required or targeted math lessons needed for the FFmpeg Assembly Lessons in the GitHub repository? It'd be easier for people to get started if everything was in one place :)
NTA but if the assumption is that the reader has only a basic understanding of C programming and wants to contribute to a video codec there is a lot of ground that needs to be covered just to get to how the cooley/tukey algorithm works and even that's just the basic fundamentals.
I read the repo more as "go through this if you want to have a greater understanding of how things work on a lower level inside your computer". In other words, presumably it's not only intended for people who want to contribute to a video codec/other parts of ffmpeg. But I'm also NTA, so could be wrong.
I think there's a generic C fallback, which can also serve as a baseline. But for the big (targeted) architectures, there one handwritten assembly version per arch.
On startup, it runs cpuid and assigns each operation the most optimal function pointer for that architecture.
In addition to things like ‘supports avx’ or ‘supports sse4’ some operations even have more explicit checks like ‘is a fifth generation celeron’. The level of optimization in that case was optimizing around the cache architecture on the cpu iirc.
Source: I did some dirty things with chromes native client and ffmpeg 10 years ago.
Yeah, sure. I was specifically referring to the tutorials. Ffmpeg needs to run everywhere, although I believe they are more concerned about data center hardware than consumer hardware. So probably also stuff like power pc.
To a first approximation, the only architectures where people really care about ffmpeg performance (anymore) are x86_64 and arm64. Everything else is of minimal importance - the few assembly routines for other architectures were probably written more for fun than for practical reasons.
You could use GAS, FASM2, or write an ffmpeg specific one: writting a real-life assembler is orders of magnitude simpler than writting a real-life compiler... Usually that implementation complexity is very dependent on the macro pre-precessor one.
This is a matter of exit cost: for instance look at linux bitkeeper->git exit.
I can’t imagine the scale that FFMPEG operates at. A small improvement has to be thousands and thousands of hours of compute saved. Insanely useful project.
Their commitment to performance is a beautiful thing.
Imagine all projects were similarly committed.
There's tons of backlash here as if people think better performance requires writing in assembly.
But to anyone complaining, I want to know, when was the last you pulled out a profiler? When was the last time you saw anyone use a profiler?
People asking for performance aren't pissed you didn't write Microsoft Word in assembly we're pissed it takes 10 seconds to open a fucking text editor.
I literally timed it on my M2 Air. 8s to open and another 1s to get a blank document. Meanwhile it took (neo)vim 0.1s and it's so fast I can't click my stopwatch fast enough to properly time it. And I'm not going to bother checking because the race isn't even close.
I'm (we're) not pissed that the code isn't optional, I'm pissed because it's slower than dialup. So take that Knuth quote you love about optimization and do what he actually suggested. Grab a fucking profiler, it is more important than your Big O
Another datapoint that supports your argument is the Grand Theft Auto Online (GTAO) thing a few months ago.[0] GTAO took 5-15 minutes to start up. Like you click the icon and 5-15 minutes later you're in the main menu. Everyone was complaining about it for years. Years. Eventually some enterprising hacker disassembled the binary and profiled it. 95% of the runtime was in `strlen()` calls. Not only was that where all the time was spent, but it was all spent `strlen()`ing the exact same ~10MB resource string. They knew exactly how large the string was because they allocated memory for it, and then read the file off the disk into that memory. Then they were tokenizing it in a loop. But their tokenization routine didn't track how big the string was, or where the end of it was, so for each token it popped off the beginning, it had to `strlen()` the entire resource file.
The enterprising hacker then wrote a simple binary patch that reduced the startup time from 5-10 minutes to like 15 seconds or something.
To me that's profound. It implies that not only was management not concerned about the start up time, but none of the developers of the project ever used a profiler. You could just glance at a flamegraph of it, see that it was a single enormous plateau of a function that should honestly be pretty fast, and anyone with an ounce of curiousity would be like, ".........wait a minute, that's weird." And then the bug would be fixed in less time than it would take to convince management that it was worth prioritizing.
It disturbs me to think that this is the kind of world we live in. Where people lack such basic curiosity. The problem wasn't that optimization was hard, (optimization can be extremely hard) it was just because nobody gave a shit and nobody was even remotely curious about bad performance. They just accepted bad performance as if that's just the way the world is.
[0] Oh god it was 4 years ago: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
I just started getting back into gaming and I'm seeing shit like this all the time. It's amazing that stuff like this is so common while the Quake fast inverse square root algo is so well known.
How is it that these companies spend millions of dollars to develop games and yet modders are making patches in a few hours fixing bugs that never get merged. Not some indie game, but AAA rated games!
I think you're right, it's on both management and the programmers. Management only knows how to rush but not what to rush. The programmers fall for the trap (afraid to push back) and never pull up a profiler. Maybe over worked and over stressed but those problems never get solved if no one speaks up and everyone is quiet and buys into the rush for rushing's sake mentality.
It's amazing how many problems could be avoided by pulling up a profiler or analysis tool (like Valgrind).
It's amazing how many millions of dollars are lost because no one ever used a profiler or analysis tool.
I'll never understand how their love for money makes them waste so much of it.
AAA games are, largely, quite bad in quality these days. Unfortunately, the desire to make a quality product (from the people who actually make the games) is overruled by the desire to maximize profit (from the people who pay their salaries). Indie games are still great, but I barely even bother to glance at AAA stuff any more.
That has been like that since there have been publishers in the games industry.
Back then, the indies stuff was only if you happened to live nearby someone you knew doing bedroom coding, distributing tapes on school, or they got lucky land their game on one of those shareware tapes collection.
Trying to actually get a publisher deal was really painful, and if you did, they really wanted their money back in sales.
Shareware tapes collection? Was there really such a thing? If so I would imagine it would be one or two demos per tape?
Yes there was such a thing, for those of us that leaved throught the 1980's.
There are tons of games that you can fit into 60m, 90m, or 180m tapes, when 48 KB/128 KB is all you got.
More like 20 or something.
Magazines like Your Sinclair and Crash would have such cassete tapes,
https://archive.org/details/YourSinclair37Jan89/YourSinclair...
https://www.crashonline.org.uk/
They would be glued into the magazine with adhesive tape, and later on to avoid them being stolen, the whole magazine plus tape would be in a plastic.
I'm just wondering if/when anyone will realize that often desire gets in the way of achieving. ̶T̶h̶e̶y̶ ̶m̶a̶y̶ ̶b̶e̶ ̶p̶e̶n̶n̶y̶ ̶w̶i̶s̶e̶ ̶b̶u̶t̶ ̶t̶h̶e̶y̶'̶r̶e̶ ̶p̶o̶u̶n̶d̶ ̶f̶o̶o̶l̶i̶s̶h̶.̶ Chasing pennies with dollars
iirc this bug existed from release but didn't impact the game until years later after a sizable number of DLCs were added to the online mode, since the function only got slower with each one added. Not that it's fine that the bug stayed in that long, but you can see how it would be missed given that when they had actual programmers running profilers at development time it wouldn't have raised any red flags after completing in ten seconds or whatever.
I don't know. As a developer there would be even more reason to be curious as to why the release binary is an order of magnitude slower then what is seen in development.
> and anyone with an ounce of curiousity would be like, ".........wait a minute"
I see what you did there ;)
Honestly the GTA5 downloader/updater itself has pretty bad configuration. I wrote a post about it on Reddit years ago along with how to fix it.
I don't know if it's still applicable or not because I haven't played it for ages, but just in case it is, here's the post: https://www.reddit.com/r/GTAV/comments/3ysv1d/pc_slow_rsc_au...
> To me that's profound. It implies that not only was management not concerned about the start up time, but none of the developers of the project ever used a profiler.
Odds are that someone did notice it during profiling and filed a ticket with the relevant team to have it fixed, which was then set to low priority because implementing the latest batch of microtransactions was more important.
I feel like this is just a natural consequence of the metrics-driven development that is so prevalent in large businesses nowadays. Management has the numbers showing them how much money they make every time they add a new microtransaction, but they don't have numbers showing them how much money they're losing due to people getting tired of waiting 15 minutes for the game to load, so the latter is simply not acknowledged as a problem.
> Grab a fucking profiler, it is more important than your Big O
This is exactly why I wrote https://jmmv.dev/2023/09/performance-is-not-big-o.html a few years back. The focus on Big O during interviews is, I think, harmful.
Your computer is broken. My M1 Pro launches it to user interactive in less than two seconds. And, to be clear, I launched it in a profiler. I suggest you do the same on your machine and find out why it's taking that long.
> People asking for performance aren't pissed you didn't write Microsoft Word in assembly we're pissed it takes 10 seconds to open a fucking text editor.
It could be worse I suppose...
Some versions of Microsoft Excel had a flight simulator embedded in them[0]!
:-D
0 - https://web.archive.org/web/20210326220319/https://eeggs.com...
"I literally timed it on my M2 Air."
I bet it opens faster on a Surface Pro
It does not. In fact, it crashes roughly every 4th or so startup.
Yikes. I'm glad I do not use Windows anymore
I mean we're talking about a fucking text editor here. A second to load is a long time even if it was on an intel i3 from 10 years ago. Because... it is a text editor... Plugins and all the fancy stuff is nice, but those can be loaded asynchronously and do not need to prevent you from jumping into a blank document.
But the god damn program is over 2GB in size... like what the fuck... There's no reason for an app I open a few times a year and have zero plugins and ONLY does text editing should even be a gig.
Seriously, get some context before you act high and mighty.
I don't know how anyone can look at Word and think it is anything but the accumulation of bloat and tech debt piling up. With decades of "it's good enough" compounding and shifting the bar lower as time goes on.
As a long time emacs user, all of that criticism hits uncomfortably close to home, much as I would like to diss Word...
As an industry we are too bad at correctness to even begin to worry about performance. Looking at FFmpeg (who are a pretty good project that I don't want to pick on too much) I see their most recent patch release fixes 3 CVEs from 2023 plus one from this year, and that's just security vulnerabilities, never mind regular bugs. Imagine if half the effort that people put into making it fast went into making it right.
like Slack or Jira... lol.
That would be an enormous waste of time. 99.9% of software doesn't have to be anywhere near optimal. It just has to not be wasteful.
Sadly lots of software is blatantly wasteful. But it doesn't take fancy assembly micro optimization to fix it, the problem is typically much higher level than that. It's more like serialized network requests, unnecessarily high time complexities, just lots of unnecessary work and unnecessary waiting.
Once you have that stuff solved you can start looking at lower level optimization, but by that point most apps are already nice and snappy so there's no reason to optimize further.
Sorry, I would word it differently. 99.9% software should be decently performant. Yes, don't need 'fancy assembly micro optimization'. That said, today some large portion of software is written by folks who absolutely doesn't care about performance - just duct-taping some sh*t to somehow make it work and call it a day.
Seems to me like we're in agreement.
People not paying attention on data structures and algorithms classes, or never bothering to learn them in first place.
Yeah no, I'd like non-performance critical programs to focus on other things than performance thank you
Hard disagree. I'd like word processors to not need ten seconds just to start up. I'd like chat clients not to use _seconds_ to echo my message back to me. I'd like news pages that don't empty my mobile data cap just by existing. All of these are “non-performance critical”, but I'd _love_ for them to focus on performance.
> I'd like news pages that don't empty my mobile data cap just by existing.
To be fair, this is because they mostly care about serving ads. Without the ads, the pages are often fine.
Many things are slow because few programmers (or managers) care. Because they'll argue about "value" but all those notions of value are made up anyways.
People argue "sure, it's not optimal, but it's good enough". But that compounds. A little slower each time. A little slower each application. You test on your VM only running your program.
But all of this forgets what makes software so powerful AND profitable: scale. Since we always need to talk monetary value, let's do that. Shaving off a second isn't much if it's one person or one time but even with a thousand users that's over 15 minutes, per usage. I mean we're talking about a world where American Airlines talks about saving $40k/yr by removing an olive and we don't want to provide that same, or more(!), value to our customers? Let's say your employee costs $100k/yr and they use that program once a day. That's 260 seconds or just under 5 minutes. Nothing, right? A measly $4. But say you have a million users. Now that's $4 million!
Now, play a fun game with me. Just go about your day as normal but pay attention to all those little speedbumps. Count them as $1m/s and let me know what you got. We're being pretty conservative here as your employee costs a lot more than their salary (2-3x) and we're ignoring slowdown being disruptive and breaking flow. But I'm willing to bet in a typical day you'll get on the order of hundreds of millions ($100m is <2 minutes).
We solve big problems by breaking them into a bunch of smaller problems, so don't forget that those small problems add up. It's true even if you don't know what big problem you're solving.
I have uBO, they're still obscenely large.
untrue. what bloats the modern web is the widespread AND suboptimal use of web frameworks. otherwise, making adblockers would dramatically speed up the loading of every website that uses ads, while it is true to some extent, is not the entire picture. anyways, i'm not saying that these libraries are always slow, but the users aren't aware of the performance characteristics and perf habits they should use while making use of such libraries. do you have any idea how many tens of layers of abstractions a "website" takes to reach your screen?
untrue. what makes bloats the modern web is competing incentives and businesses choosing what they think is going to make them the most money.
So you’re a PM for a word processor. You have a giant backlog.
Users want to load and edit PDFs. Finnish has been rendering right to left for months, but the easy fix will break Hebrew. The engineers say a new rendering engine is critical or these things will just get worse. Sales team says they’re blocked on a significant contract because the version tracking system allows unaudited “clear history” operations. Reddit is going berserk because the icon you used (and paid for!) for the new “illuminated text mode” turns out to be stolen from a Lithuanian sports team.
Knowing that most of your users only start the app when their OS forces a reboot… just how much priority does startup time get?
This is an incredibly convoluted hypothetical trying to negate the idea that users notice and/or appreciate how quickly their applications start. Usually as a PM you are managing multiple engineers, one of which I would assume is capable of debugging and eventually implementing a fix for faster start times. Even if they can't fix it immediately due to whatever contrived reason you've supposed, at least they will know where and how to fix it when the time does come. In fact, I would argue pretending there is no issue because of your mountain of other problems is the worst possible scenario to be in.
I don't think that fits MS Office. The situation is more that you have a working, usable word processor which has all the festures your user needs. Since many years ago. But your UI designer thinks it can be a little more beautiful but much slower. Of course you give that way too much priority.
On my Laptop where I am forced by my company to run windows, I run word 2010 and it runs far better(speed and stability) that the newest word I have to use ob my office pc.
Many of the important decisions are made at design and review time. When that team adds PDF support, they should act unlike the Explorer team and avoid unnecessary O(n^2) algorithms.
Part of getting this to happen is setting the right culture and incentives. PM is such a nebulous term that I can't say this definitively, but I don't think the responsibility for this lies with them. Some poor performance is simply tech debt and should be tackled in the same way.
$WORD_PROCESSOR employees should be capable of this: we've all seen how they interview.
When I was in school I had a laundry app (forced to use) that took 8 seconds to load, mostly while it scanned the network for the machines. It also had the rooms out of order in the room listing and no caching so every time you wanted to check the status (assuming it even worked) it took no less than a minute. It usually took less time to physically check, which also had a 100% accuracy.
Fuck this "we don't need to optimize" bullshit. Fuck this "minimum viable product" bullshit. It's just a race to the bottom. No one paper cut is the cause of death, but all of them are when you have a thousand.
> None of these are “non-performance critical”, but I'd _love_ for them to focus on performance
Then you agree with the poster. Performance critical software should focus on performance.
This mentality brings you a loading screen when you start the calculator on windows.
What? Calculator starts up faster than I can figure out on where and on which screen it decided to open
On this machine it took me about 8 seconds to get the start menu open, about 5 seconds to get it to recognize that I'd typed "calc", another 5 seconds for it to let me actually select it to launch, and then about 20 seconds from the calculator window appearing - in its empty loading state - for it to actually come up. I admit this computer is several years old - but ... it's... a calculator.
On Windows 11 I can see a startup screen briefly before it loads the calculator buttons -- takes maybe 2 seconds all up -- seems to be 1 seconds to start up screen then another second to populate the buttons. But can understand why people feel it's a regression though as I reall the win95/98/me calc.exe would pretty much appear near instantly even on the CPU/RAM/etc of the day.
I'm currently on a Windows 10 machine with Core i5 that's more than a decade old. The calculator takes a couple of seconds to start up - provided it's a "good" day (i.e. one when Windows isn't downloading updates or doing search indexing or malware scanning in the background.)
But I also have a Core 2 Duo-based WinXP machine in easy reach (just to keep a legacy software environment alive) and its keyboard has a dedicated calculator button. The calculator is just there the moment I press that button - it's appeared long before I can even release the button.
echo ${calculation} into bc works as fast as your fingers
Surely all programs are performance critical. Any program we think isn't is just a program where the performance met the criteria already.
Safety critical systems say hello.
> Safety critical systems
Any concrete examples where we can see the code?
sqlite is probably our best example. The project touts use within Airbus A350 and DO-178B certification.
Indeed. All else remaining the same, a faster program is generally more desirable than a slower program, but we don't live in generalities where all else remains the same and we simply need to choose fast over slow. Fast often costs more to produce.
Programming is a small piece of a larger context. What makes a program "good" is not a property of the program itself, but measured by external ends and constraints. This is true of all technology. Some of these constraints are resources, and one of these resources is time. In fact, the very same limitation on time that motivates the prioritization of development effort toward some features other than performance is the very same limitation that motivates the desire for performance in the first place.
Performance must be understood globally. Let's say we need a result in three days, and it takes two days to write a program that takes one day to get the result, but a week to write a program that takes a second to produce a result, then obviously, it is better to write the program the first way. In a week's time, your fast program will no longer be needed! The value of the result will have expired.
This is effectively a matter of opportunity cost.
There's nothing more permanent than a temporary fix that works.
Seems so easy! You only need the entire world even tangentially related to video to rely solely on your project for a task and you too can have all the developers you need to work on performance!
ffmpeg has competition. For the longest time it wasn't the best audio encoder for any codec[0], and it wasn't the fastest H.264 decoder when everyone wanted that because a closed-source codec named CoreAVC was better[1].
ffmpeg was however, always the best open-source project, basically because it had all the smart developers who were capable of collaborating on anything. Its competition either wasn't smart enough and got lost in useless architecture-astronauting[2], or were too contrarian and refused to believe their encoder quality could get better because they designed it based on artificial PSNR benchmarks instead of actually watching the output.
[0] For complicated reasons I don't fully understand myself, audio encoders don't get quality improvements by sharing code or developers the way decoders do. Basically because they use something called "psychoacoustic models" which are always designed for the specific codec instead of generalized. It might just be that noone's invented a way to do it yet.
[1] I eventually fixed this by writing a new multithreading system, but it took me ~2 years of working off summer of code grants, because this was before there was much commercial interest in it.
[2] This seems to happen whenever I see anyone try to write anything in C++. They just spend all day figuring out how to connect things to other things and never write the part that does anything?
At least they get there.
I was thinking about two types of people; one gets distracted and starts writing their own UI framework and standard library and never gets back to the program. The other starts writing a super-flexible plugin system for everything because they're overly concerned with developing a community to the point they don't want to actually implement anything themselves.
(In this space the first was a few different mplayer forks and the second was gstreamer.)
Sometimes they get there but a lot of times not too.
I'm pretty sure there are a lot more types and the two you wrote aren't the copy-pasters either. Me, I try to follow the Unix philosophy[0] though I think there's plenty of exceptions to be made. Basically just write a bunch of functions and make your functions simple. Function overhead calls are usually cheap so this allows things to be very flexible. Because the biggest lesson I've learned is that the software is going to change so it is best to write with this in mind. The best laid plans of mice and men and all I guess. So write for today but don't forget about tomorrow.
Then of course there are those that love abstractions, those that optimize needlessly, and many others. But I do feel the copy-pasters are the most common type these days.
[0] https://en.wikipedia.org/wiki/Unix_philosophy
That's a fun term for [2]. Our team always called it bikeshedding.
I seem to recall that they lamented on twitter the low amount of (monetary or code) contribution they got, despite how heavily they are used.
They have some fire tweets, especially when people say they write things from scratch or boast about how much money they make with ffmpeg wrappers
https://x.com/FFmpeg/status/1775178803129602500
https://x.com/FFmpeg/status/1856078171017281691
https://x.com/FFmpeg/status/1950227075576823817
Oh, and here's one making fun of HN comments. Hi ffmpeg :) https://x.com/FFmpeg/status/1947076489880486131
Wasn’t that a trillion dollar company demanding support for their little problem?
No one is forcing them to produce code for free. There is something toxic about giving things away for free with the ulterior motive of getting money for it.
It’s market manipulation, with the understanding that free beats every other metric.
Once the competition fails, the value extraction process can begin. This is where the toxicity of our city begins to manifest. Once there is no competition remaining we can begin eating seeds as a pastime activity.
The toxicity of our city; our city. How do you own the world? Disorder.
Disorder…
You know friend, if open source actually worked like that I wouldn’t be so allergic to releasing projects. But it doesn’t - a large swath of the economy depends on unpaid labour being treated poorly by people who won’t or can’t contribute.
> Imagine all projects were similarly committed.
How many projects would have anything to benefit from this focus on optimization, though?
There is a reason why the first rule of optimization is "don't do it", and the second (experts only) is "don't do it yet".
It'd be nice, though, to have a proper API (in the traditional sense, not SaaS) instead of having to figure out these command lines in what's practically its own programming language....
FFMpeg does have an API. It ships a few libraries (libavcodec, libavformat, and others) which expose a C api that is used in the ffmpeg command line tool.
They publish doxygen generated documentation for the APIs, available here: https://ffmpeg.org/doxygen/trunk/
Don't know how I overlooked that, thanks. Maybe because the one Python wrapper I know about is generating command lines and making subprocess calls.
They're relatively low level APIs. Great if you're a C developer, but for most things you'd do in python just calling the command line probably does make more sense.
As someone that used these APIs in C, they were not very well-documented nor intuitive, and oftentimes segfaulted when you messed up, instead of returning errors—I suppose the validation checks sacrifice performance for correctness, which is undesirable. Either way, dealing with this is not fun. Such is the life of a C developer, I suppose....
It could even make sense in C. In some circumstances, I wouldn’t feel bad for cutting that corner.
Yes, that's what I did some time ago. I already want concurrency and isolation, so why not let the OS do that. Also I don't need to manage resources, when ffmpeg already does that.
For future reference, if you want proper python bindings for ffmpeg* you should use pyav.
* To be more precise, these are bindings for the libav* libraries that underlie ffmpeg
If you are processing user data, the subprocess approach makes it easier to handle bogus or corrupt data. If something is off, you can just kill the subprocess. If something is wrong with the linked C api, it can be harder to handle predictably.
Also because you can apply stricter sandboxing/jail/containerization to the process.
I get why the CLI is so complicated, but I will say AI has been great at figuring out what I need to run given an English language input. It's been one of the highest value uses of AI for me.
hell yeah, same here. i made a little python GUI app to edit videos
I would be interested in more examples where "assembly is faster than intrinsics". I.e., when the compiler screws up. I generally write Zig code with the expectation of a specific sequence of instructions being emitted, and I usually get it via the high level wrappers in std.simd + a few llvm intrinsics. If those fail I'll use inline assembly to force a particular instruction. On extremely rare occasions I'll rely on auto-vectorization, if it's good and I want it to fall back on scalar on less sophisticated CPU targets (although sometimes it's the compiler that lacks sophistication). Aside from the glaring holes in the VPTERNLOG finder, I feel that instruction selection is generally good enough that I can get whatever I want.
The bigger issue is instruction ordering and register allocation. On code where the compiler effectively has to lower serially-dependent small snippets independently, I think the compiler does a great job. However, when it comes to massive amounts of open code I'm shocked at how silly the decisions are that the compiler makes. I see super trivial optimizations available at a glance. Things like spilling x and y to memory, just so it can read them both in to do an AND, and spill it again. Constant re-use is unfortunately super easy to break: Often just changing the type in the IR makes it look different to the compiler. It also seems unable to merge partially poisoned (undefined) constants with other constants that are the same in all the defined portions. Even when you write the code in such a way where you use the same constant twice to get around the issue, it will give you two separate constants instead.
I hope we can fix these sorts of things in compilers. This is just my experience. Let me know if I left anything out.
>There are two flavours of x86 assembly syntax that you’ll see online: AT&T and Intel. AT&T Syntax is older and harder to read compared to Intel syntax. So we will use Intel syntax.
God bless you, ffmpeg.
Prior discussion 2025-02-22, 222 comments: https://news.ycombinator.com/item?id=43140614
I was expecting to read pearls of wisdom gleaned from all the hard work done on the project, but I’m not really getting how this relates to ffmpeg.
The few chapters I saw seemed to be pretty generic intro to assembly language type stuff.
It's intended to get people up to speed on assembly so they can contribute to FFmpeg.
What is the actual process of identifying hotspots caused suboptimal compiler generated assembly?
Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
So the main issues here are not what people think they are. They generally aren't "suboptimal assembly", at least not what you can reasonably expect out of a C compiler.
The factors are something like:
- specialization: there's already a decent plain-C implementation of the loop, asm/SIMD versions are added on for specific hardware platforms. And different platforms have different SIMD features, so it's hard to generalize them.
- predictability: users have different compiler versions, so even if there is a good one out there not everyone is going to use it.
- optimization difficulties: C's memory model specifically makes optimization difficult here because video is `char *` and `char *` aliases everything. Also, the two kinds of features compilers add for this (intrinsics and autovectorization) can fight each other and make things worse than nothing.
- taste: you could imagine a better portable language for writing SIMD in, but C isn't it. And on Intel C with intrinsics definitely isn't it, because their stuff was invented by Microsoft, who were famous for having absolutely no aesthetic taste in anything. The assembly is /more/ readable than C would be because it'd all be function calls with names like `_mm_movemask_epi8`.
One time I spent a week carefully rewriting all of the SIMD asm in libtheora, really pulling out all of the stops to go after every last cycle [0], and managed to squeeze out 1% faster total decoder performance. Then I spent a day reorganizing some structs in the C code and got 7%. I think about that a lot when I decide what optimizations to go after.
[0] https://gitlab.xiph.org/xiph/theora/-/blob/main/lib/x86/mmxl... is an example of what we are talking about here.
Unfortunately modern processors do not work how most people think they do. Optimizing for less work for a nebulous idea of what "work" is generally loses to bad memory access patterns or just using better instructions that seem most expensive if you look at them superficially.
It can be sobering to consider how many instructions a modern CPU can execute in case of a cache miss.
In the timespan of a L1 miss, the CPU could execute several dozen instructions assuming a L2 hit, hundreds if it needs to go to L3.
No wonder optimizing memory access can work wonders.
> And on Intel C with intrinsics definitely isn't it, because their stuff was invented by Microsoft, who were famous for having absolutely no aesthetic taste in anything.
Wouldn't Intel be the one defining the intrinsics? They're referenced from the ISA manuals, and the Intel Intrinsics Guide regularly references intrinsics like _allow_cpu_features() that are only supported by the Intel compiler and aren't implemented in MSVC.
The _emm _epi8 stuff is Hungarian notation, which is from Microsoft.
Uh, no, that's standard practice for disambiguating the intrinsic operations for different data types without overloading support. ARM does the same thing with their vector intrinsics, such as vaddq_u8(), vaddq_s16(), etc.
Normally you spin up a tool like vtune or uprof to analyze your benchmark hotspots at the ISA level. No idea about tools like that for ARM.
> Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
IME, not really. I've done a fair bit of hand-written assembly and it exclusively comes up when dealing with architecture-specific problems - for everything else you can just write C (unless you hit one of the edge cases where C semantics don't allow you to express something in C, but those are rare).
For example: C and C++ compilers are really, really good at writing optimized code in general. Where they tend to be worse are things like vectorized code which requires you to redesign algorithms such that they can use fast vector instructions, and even then, you'll have to resort to compiler intrinsics to use the instructions at all, and even then, compiler intrinsics can lead to some bad codegen. So your code winds up being non-portable, looks like assembly, and has some overhead just because of what the compiler emits (and can't optimize). So you wind up just writing it in asm anyway, and get smarter about things the compiler worries about like register allocation and out-of-order instructions.
But the real problem once you get into this domain is that you simply cannot tell at a glance whether hand written assembly is "better" (insert your metric for "better here) than what the compiler emits. You must measure and benchmark, and those benchmarks have to be meaningful.
> Normally you spin up a tool like vtune or uprof to analyze your benchmark hotspots at the ISA level. No idea about tools like that for ARM.
perf is included with the Linux kernel, and works with a fair amount of architectures (including Arm).
You may still need to install linux-tools to get the perf command.
It's included with the kernel as distributed by upstream. Your distribution may choose to split out parts of it into other binary packages.
I'm not disagreeing, I just wanted to add so others might know why they can't just run the command.
perf doesn't give you instruction level profiling, does it? I thought the traces were mostly at the symbol level
Hit enter on the symbol, and you get instruction-level profiles. Or use perf annotate explicitly. (The profiles are inherently instruction-level, but the default perf report view aggregates them into function-level for ease of viewing.)
> Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
Not really. There are a couple of reasons to reach for handwritten assembly, and in every case, IR is just not the right choice:
If your goal is to ensure vector code, your first choice is to try slapping explicit vectorize-me pragmas onto the loop. If that fails, your next effort is either to use generic or arch-specific vector intrinsics (or jump to something like ISPC, a language for writing SIMT-like vector code). You don't really gain anything in this use case from jumping to IR, since the intrinsics will satisfy your code.
If your goal is to work around compiler suboptimality in register allocation or instruction selection... well, trying to write it in IR gives the compiler a very high likelihood of simply recanonicalizing the exact sequence you wrote to the same sequence the original code would have produced for no actual difference in code. Compiler IR doesn't add anything to the code; it just creates an extra layer that uses an unstable and harder-to-use interface for writing code. To produce the best handwritten version of assembly in these cases, you have to go straight to writing the assembly you wanted anyways.
Loop vectorization doesn't work for ffmpeg's needs because the kernels are too small and specialized. It works better for scientific/numeric computing.
You could invent a DSL for writing the kernels in… but they did, it's x86inc.asm. I agree ispc is close to something that could work.
Shame this doesn't start with a quick introduction to running the examples with an actual assembler like NASM.
Why not include the required or targeted math lessons needed for the FFmpeg Assembly Lessons in the GitHub repository? It'd be easier for people to get started if everything was in one place :)
NTA but if the assumption is that the reader has only a basic understanding of C programming and wants to contribute to a video codec there is a lot of ground that needs to be covered just to get to how the cooley/tukey algorithm works and even that's just the basic fundamentals.
I read the repo more as "go through this if you want to have a greater understanding of how things work on a lower level inside your computer". In other words, presumably it's not only intended for people who want to contribute to a video codec/other parts of ffmpeg. But I'm also NTA, so could be wrong.
How do they make these assembly instructions portable across different cpus?
I think there's a generic C fallback, which can also serve as a baseline. But for the big (targeted) architectures, there one handwritten assembly version per arch.
Yup.
On startup, it runs cpuid and assigns each operation the most optimal function pointer for that architecture.
In addition to things like ‘supports avx’ or ‘supports sse4’ some operations even have more explicit checks like ‘is a fifth generation celeron’. The level of optimization in that case was optimizing around the cache architecture on the cpu iirc.
Source: I did some dirty things with chromes native client and ffmpeg 10 years ago.
They don't. It's just x86-64.
The lessons yes, but the repo contains assembly for the 5-6 architectures in wide use in consumer hardware today. Separate files of course. https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec
Yeah, sure. I was specifically referring to the tutorials. Ffmpeg needs to run everywhere, although I believe they are more concerned about data center hardware than consumer hardware. So probably also stuff like power pc.
To a first approximation, the only architectures where people really care about ffmpeg performance (anymore) are x86_64 and arm64. Everything else is of minimal importance - the few assembly routines for other architectures were probably written more for fun than for practical reasons.
Love it. Thanks for taking the time to write this. Hope it will encourage more folks to contribute.
More interesting than I thought it could be. A domain specific tutorial is so much better.
There is serious abuse of nasm macro-preprocessor. Going to be tough to move away to another assembler.
Why move away?
Not everyone wants to use nasm. Sometimes all you have is the clang integrated assembler :(
Yep, look at nasm SDK, horrible, with tons of perl generators, etc, etc. From the worst.
You could use GAS, FASM2, or write an ffmpeg specific one: writting a real-life assembler is orders of magnitude simpler than writting a real-life compiler... Usually that implementation complexity is very dependent on the macro pre-precessor one.
This is a matter of exit cost: for instance look at linux bitkeeper->git exit.
Where? There's very little code in those lessons
The lessons reference `cglobal` in `x86inc.asm`:
https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/x...
I feel like I just got a 3 page intro to autism.
It's glorious.