6 ms·

It's funny reading comments here, Hackernews bros really think they're smarter than the guys who made ffmpeg/x264/x265 etc. Dunning–Kruger effect in action.

by Glacia 3y ago

janwas 3y ago
FWIW I have been writing SIMD since 20+ years and worked on JPEG XL, which also contains a good bit of vector code. BTW one anecdote: a colleague mentioned what should have been a quick 20 min patch to ffmpeg took a day because it was written in assembly.
- Glacia 3y ago
  Here is the old archived blog post where x264 team answered in the comments why they do it that way. https://web.archive.org/web/20091223024333/http://x264dev.multimedia.cx/?p=191#comments https://web.archive.org/web/20091223024333/http://x264dev.mu...
  - exDM69 3y ago
    This is dated to 2009. Probably sound advise back then. Compilers are much much better with SIMD code than they were then. Today you'll have to work real hard to beat LLVM in optimizing basic SIMD code (edit: when given SIMD code as input, see comment below). I happen to know because this "hacker news bro" has been dealing with SIMD code for longer than that.
    - kierank 3y ago
      FFmpeg code by definition is not "basic SIMD code". And it supports numerous other compilers other than LLVM.
    - jbk 3y ago
      > Today you'll have to work real hard to beat LLVM in optimizing basic SIMD code. On dav1d, we see just a 800% increase… I know it’s negligible, but…
      - exDM69 3y ago
        Compared to what? Scalar loopy C code sure. The auto vectorization is not great. But give LLVM some SIMD code as input, and it will be able to optimize it, and it does a great job with register allocation, spill code, instruction scheduling etc. Instruction selection isn't as great and you still need to use intrinsics for specialized instructions. And you get all of this for all CPU architectures and will deal with future microarchitecture changes for free. E.g. more execution ports added by Intel will get used with no code changes on your side. With infinite time you can still do better by hand, but it gets expensive fast, especially if you have several CPU architectures to deal with.
        jbk 3y ago
        > Scalar loopy C code sure. The auto vectorization is not great. Stop considering people as idiots. People do that because it’s a LOT faster, not just a bit. If you are so able, please show us your results. Dav1d is full open source, fully documented, and with quite simple C code. Show your results.
        Const-me 3y ago
        > show us your results Not GP but here’s an example where intrinsics outperformed assembly by an order of magnitude: https://news.ycombinator.com/item?id=36624240 https://news.ycombinator.com/item?id=36624240 They were AVX2 SIMD intrinsics versus scalar assembly, but I doubt AVX2 assembly gonna substantially improve performance of my C++. The compiler did a decent job allocating these vector registers and the assembly code is not too bad, not much to improve. It’s interesting how close your 800% to my 1000%. For this reason, I have a suspicion you tested the opposite, naïve C or C++ versus SIMD assembly. Or maybe you have tested automatically vectorized C or C++ code, automatic vectorizers often fail to deliver anything good.
        Glacia 3y ago
        So you took asm code that had no SIMD instructions in it, made your own version in c++ with intrinsics and figured out that, yes, SIMD is faster? Realy? I think you're completely missing what are we talking about here.
- kierank 3y ago
  That "20 minute patch" will need to be maintained for decades to come in FFmpeg, long after a standalone JPEG-XL library. Potentially centuries as archives like the Library of Congress are storing FFmpeg. So that's why it's done in assembly, so it's maintainable with the rest of the code.
JonChesterfield 3y ago
First you write in C. Then it's too slow, you write parts in asm. After a while you have a lot of asm. You lean harder on the macro processor. At some point you port to another processor and decide the macro processor can handle that. Bang, x86inc.asm. That doesn't make the end point optimal. Nor does it mean it's what the authors would have done from a clean slate. At each step you take the sensible choice and after a long trek down the gradient you end up somewhere like this. Given a desire to write something analogous to these codecs today, should you copy their development path? Should you try to copy the end result, maybe even using the same tools? Your argument from authority amounts to "these guys are clever, you should imitate them". There are failure modes in that line of thinking which I hope the above makes clear.
- astrange 3y ago
  We aren't stupid. We designed x86inc to be like that for good reasons, from a clean slate, and if we didn't like it we would have done something else. You haven't tested the alternatives - they're slow and don't work in this situation, mostly because C is not actually that low level when it comes to memory aliasing.
  - JonChesterfield 3y ago
    Well that's much more interesting. Is there anything written publicly about the experience? Any tooling used to help get the implementation right beyond testing and writing it carefully? I've found a little here https://ffmpeg.org/developer.html#SIMD_002fDSP-1 https://ffmpeg.org/developer.html#SIMD_002fDSP-1 The context is I'm a compiler developer who really liked working side by side with old school assembly developers in a past role. I'm painfully aware that the tribal knowledge of building stuff out of asm is hard to find written down and always curious about the directions in which things like C can be extended to narrow the gap.
- deleted 3y ago
  [deleted]

It's funny reading comments here, Hackernews bros really think they're smarter than the guys who made ffmpeg/x264/x265 etc. Dunning–Kruger effect in action.

by Glacia 3y ago

It's funny reading comments here, Hackernews bros really think they're smarter than the guys who made ffmpeg/x264/x265 etc. Dunning–Kruger effect in action.

janwas 3y ago

FWIW I have been writing SIMD since 20+ years and worked on JPEG XL, which also contains a good bit of vector code. BTW one anecdote: a colleague mentioned what should have been a quick 20 min patch to ffmpeg took a day because it was written in assembly.

Glacia 3y ago
Here is the old archived blog post where x264 team answered in the comments why they do it that way. https://web.archive.org/web/20091223024333/http://x264dev.multimedia.cx/?p=191#comments https://web.archive.org/web/20091223024333/http://x264dev.mu...
- exDM69 3y ago
  This is dated to 2009. Probably sound advise back then. Compilers are much much better with SIMD code than they were then. Today you'll have to work real hard to beat LLVM in optimizing basic SIMD code (edit: when given SIMD code as input, see comment below). I happen to know because this "hacker news bro" has been dealing with SIMD code for longer than that.
  - kierank 3y ago
    FFmpeg code by definition is not "basic SIMD code". And it supports numerous other compilers other than LLVM.
  - jbk 3y ago
    > Today you'll have to work real hard to beat LLVM in optimizing basic SIMD code. On dav1d, we see just a 800% increase… I know it’s negligible, but…
    - exDM69 3y ago
      Compared to what? Scalar loopy C code sure. The auto vectorization is not great. But give LLVM some SIMD code as input, and it will be able to optimize it, and it does a great job with register allocation, spill code, instruction scheduling etc. Instruction selection isn't as great and you still need to use intrinsics for specialized instructions. And you get all of this for all CPU architectures and will deal with future microarchitecture changes for free. E.g. more execution ports added by Intel will get used with no code changes on your side. With infinite time you can still do better by hand, but it gets expensive fast, especially if you have several CPU architectures to deal with.
      - jbk 3y ago
        > Scalar loopy C code sure. The auto vectorization is not great. Stop considering people as idiots. People do that because it’s a LOT faster, not just a bit. If you are so able, please show us your results. Dav1d is full open source, fully documented, and with quite simple C code. Show your results.
        Const-me 3y ago
        > show us your results Not GP but here’s an example where intrinsics outperformed assembly by an order of magnitude: https://news.ycombinator.com/item?id=36624240 https://news.ycombinator.com/item?id=36624240 They were AVX2 SIMD intrinsics versus scalar assembly, but I doubt AVX2 assembly gonna substantially improve performance of my C++. The compiler did a decent job allocating these vector registers and the assembly code is not too bad, not much to improve. It’s interesting how close your 800% to my 1000%. For this reason, I have a suspicion you tested the opposite, naïve C or C++ versus SIMD assembly. Or maybe you have tested automatically vectorized C or C++ code, automatic vectorizers often fail to deliver anything good.
        Glacia 3y ago
        So you took asm code that had no SIMD instructions in it, made your own version in c++ with intrinsics and figured out that, yes, SIMD is faster? Realy? I think you're completely missing what are we talking about here.
kierank 3y ago
That "20 minute patch" will need to be maintained for decades to come in FFmpeg, long after a standalone JPEG-XL library. Potentially centuries as archives like the Library of Congress are storing FFmpeg. So that's why it's done in assembly, so it's maintainable with the rest of the code.

JonChesterfield 3y ago

First you write in C. Then it's too slow, you write parts in asm. After a while you have a lot of asm. You lean harder on the macro processor. At some point you port to another processor and decide the macro processor can handle that. Bang, x86inc.asm. That doesn't make the end point optimal. Nor does it mean it's what the authors would have done from a clean slate. At each step you take the sensible choice and after a long trek down the gradient you end up somewhere like this. Given a desire to write something analogous to these codecs today, should you copy their development path? Should you try to copy the end result, maybe even using the same tools? Your argument from authority amounts to "these guys are clever, you should imitate them". There are failure modes in that line of thinking which I hope the above makes clear.

astrange 3y ago
We aren't stupid. We designed x86inc to be like that for good reasons, from a clean slate, and if we didn't like it we would have done something else. You haven't tested the alternatives - they're slow and don't work in this situation, mostly because C is not actually that low level when it comes to memory aliasing.
- JonChesterfield 3y ago
  Well that's much more interesting. Is there anything written publicly about the experience? Any tooling used to help get the implementation right beyond testing and writing it carefully? I've found a little here https://ffmpeg.org/developer.html#SIMD_002fDSP-1 https://ffmpeg.org/developer.html#SIMD_002fDSP-1 The context is I'm a compiler developer who really liked working side by side with old school assembly developers in a past role. I'm painfully aware that the tribal knowledge of building stuff out of asm is hard to find written down and always curious about the directions in which things like C can be extended to narrow the gap.
deleted 3y ago
[deleted]