Headline: "FFmpeg devs boast of another 100x leap thanks to handwritten assembly code"
Text: "... this boost is only seen in an obscure filter", "... up to ... %"
[expletives omitted]
FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
101–110 of 138 posts
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#102When I spent a decade doing SIMD optimizations for HEVC (among other things), it was sort of a joke to compare the assembly versions to plain c. Because you’d get some ridiculous multipliers like 100x. It is pretty misleading, what it really means is it was extremely inefficient to begin with. The devil is in the details, microbenchmarks are typically calling the same function a million times in a loop and everything…
Does FFmpeg and co have "macrobenchmarks" as well? I would imagine software like that would have a diverse set of videos and a bajillion different encoding / decoding / transformation sets that are used to measure performance (time, cpu, file size, quality) over time. But it would need dedicated and consistent hardware to test all of that.
You don't actually need neither dedicated nor consistent hardware, if you are willing to do some statistics.
Basically, you'd do a block design (https://en.wikipedia.org/wiki/Blocking_(statistics)): on any random hardware you have, you run both versions back to back (or even better, interleaved), and note down the performance.
The idea that the differences in machines themselves and anything else running on them are noise, and you are trying to design your experiments in such a way that the noise should affect arms of the experiment in the same way---at least statistically.
Downsides: you have to do more runs and do more statistics to deal with the noise.
Upside: you can use any old hardware you have access to, even if it's not dedicated. And the numbers are arguably going to be more representative of real conditions, and not just a pristine lab environment.
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#103Earlier quoted context omitted.
Sorry for the derail, but it sounds like you have a ton of experience with SIMD. Have you used ISPC, and what are your thoughts on it? I feel it's a bit ridiculous that in this day and age you have to write SIMD code by hand, as regular compilers suck at auto-vectorizing, especially as this has never been the case with GPU kernels.
Personally I’ve never been able to beat gcc or icx autovectorization by using intrinsics; often I’m slower by a factor of 1.5-2x. Do you have any wisdom you can share about techniques or references you can point to?
You may not be able to beat the auto-vectorizer for problems which can be auto-vectorized, but you have almost certainly encountered situations which the compiler can't auto-vectorize but where you could've manually written a SIMD implementation which beats the compiler's scalar code.
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#104To be fair to the dev he said he sped up one function 100x.
That doesn't imply he speed up the program. Ironically speeding up parts of code may decrease overall performance due to resource contention.
As the saying goes. There are lies, damned lies, statistics, and then benchmarking.
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#105Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#106Earlier quoted context omitted.
You're missing the point. All instructions can be simplified to short integer operations, then all integer operations are just networks of gates, then all gates can be replaced with AND/OR/NOT, or even just NAND. That's why you can SAT solve program equivalence. See SMT2 programs using BV theory for example. Also of course all instructions are MOV anyway. https://github.com/xoreaxeaxeax/movfuscator
I seem to remember that program equivalence is an NP-hard problem. I very much doubt that you can solve it by reducing it to logic gates.
That's why superoptimizers work on short sequences of code and take a long time doing so.
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#107Earlier quoted context omitted.
I seem to remember that program equivalence is an NP-hard problem. I very much doubt that you can solve it by reducing it to logic gates.
NP-hard is just a complexity class, not a minimal threshold. SAT solving is kind of a guided optimistic bruteforcing. If the example is small enough, you can still solve it very quickly. Same as you can solve travelling salesman for a small number of cities. We solve small cases of NP-hard things all over the place.
(not to confirm it's an np-hard problem - it may not even be decidable generally, but in practice yes, you can check it that way and SMT2 theories provide the right ops)
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#108When I spent a decade doing SIMD optimizations for HEVC (among other things), it was sort of a joke to compare the assembly versions to plain c. Because you’d get some ridiculous multipliers like 100x. It is pretty misleading, what it really means is it was extremely inefficient to begin with. The devil is in the details, microbenchmarks are typically calling the same function a million times in a loop and everything…
ffmpeg is not too different from a microbenchmark, the whole program is basically just: while (read(buf)) write(transform(buf))
/r/restofthefuckingowl
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#109Article is unclear what will actually be affected. It mentions "rangedetect8_avx512" and calls it an obscure function. So, what situations is it actually used for, and what is the real-time improvement in performance for the entire conversion process?
Back in ye olden tymes, video was an analog signal. It was wibbly wobbly waves. You could look at them with an oscilloscope. One of the things that it used to do to make stuff work was to encode control stuff in band. This is sorta like putting editor notes in a text file. There might be something like . In particular, it used blacks which were blacker than black to signal when it was time to go to the next line, or…
I’m positive you know this already, but for anyone else, this section [0] of the lddecode project has a wonderful example of all the visible and non-visible portions of an analog video signal.
The project as a whole is also utterly fascinating, if you find the idea of pulling an analog RF signal from a laser and then doing software ADC interesting.
[0]: https://github.com/happycube/ld-decode/wiki/ld-analyse#under...
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#110Earlier quoted context omitted.
All instructions are implemented with logic gates. In fact. All instructions today are likely NAND gates. Have you ever seen a WallaceTree multiplier? A good sequence that shows how XOR and AND gates can implement multiply. Now, if multiply + XOR gets the new function you want, it's likely better than whatever the original compiler output.
That was not the claim. The claim was that assembler was made up out of sequences of OR/AND/XOR, and that claim is demonstrably false.
You're missing forest for the trees and lacking information to discuss this really. Check out this paper and similar ones if you want to learn about this area: https://arxiv.org/pdf/1711.04422