6 ms·

Improving performance of original dav1d video decoder

50 points by ycomb_anon 1y ago

ycomb_anon 1y ago
Testing has not been fully completed yet, but if PR merge. rav1d will become even more difficult to optimize. How much real data alignment helps? Wouldn't -O3 with -Ofast do all code optimization for programmer. Contributor dav1d claims 1-3% growth after his optimization, depending on video dataset payload. He nullified 1% optimization in rav1d, if the real growth was 3%, rav1d will not soon be able to equalize benchmark results. Another question in theory can Rust be faster than C? If all possible optimizations are applied.
- refulgentis 1y ago
  > Wouldn't -O3 with -Ofast do all code optimization for programmer. No? > Contributor dav1d claims 1-3% growth after his optimization, depending on video dataset payload. He nullified 1% optimization in rav1d, if the real growth was 3%, rav1d will not soon be able to equalize benchmark results. Aren't you the contributor? (You have a very unique writing voice) > Another question in theory can Rust be faster than C? If all possible optimizations are applied. I don't see why not? Other than that: A) Great work! B) Unsolicited advice, apologies: your technical acumen is being outshadowed by projection of motivations. They're just programming languages. There's no way to say one is definitely better than the other, and no guarantee one will be faster or slower than the other. Your forebears had similar arguments about C and assembler. Yet, neither of us is surprised to find there is no asmav1d. (and that's much more clean-cut of an argument w/r/t speed!) (I don't think it was the goal of a long-running FOSS project to advertise Rust is almost as fast as C when they offered a bounty)
- pdimitar 1y ago
  > Another question in theory can Rust be faster than C? If all possible optimizations are applied. Very likely not at this stage, and maybe not for years to come. But I'll take increased memory safety and elimination of entire class of bugs for 1-3% performance loss even on the most critical paths (with many actual wins for Rust in many other cases). While I do get what huge battery life implications might 5% differences in decoders make, I believe the current political climate mandates we use the most secure code we can and sacrifice smidgen bits of performance here and there for it. It was known for decades that at one point we'll have to roll up our sleeves and pay up the security tech debt. Sorry for the slightly philosophical message but I've no desire to comment on the actual tech details here.
  - hulitu 1y ago
    > It was known for decades that at one point we'll have to roll up our sleeves and pay up the security tech debt. Yes, we are paying up the security tech debt. It is called "checklist security compliance". BTW, is there any rust project audited for security ?
brooke2k 1y ago
I don't understand the vitriol this author seems to have towards rav1d/Rust. It's just a separate implementation of the project. Slower, faster, who cares? Getting so attached to "which language is faster" seems a tad dramatic. But maybe I'm over-reading into what's actually friendly competition. The tone just seems oddly aggressive.
- mmastrac 1y ago
  I would guess the author is young and smart, but hasn't spent much time working with others. I've seen this in other developers with lots of potential. It usually takes a few years of mentorship to smooth the rough edges.
- tgma 1y ago
  [flagged]
- Thaxll 1y ago
  Well apparently the so called just 5% slower than dav1d is not true according to other benchmark, it's much slower.
  - MallocVoidstar 1y ago
    What other benchmark?
    - ZeroGravitas 1y ago
      One of the dav1d team shared a benchmark on twitter suggesting that single core rav1d was about 6% slower than dav1d but multicore was 35% slower. https://nitter.net/rbultje/status/1924136075426951200 https://nitter.net/rbultje/status/1924136075426951200 But the rav1d project has 8 core benchmarks on their GitHub suggesting more like 8-10% slower on arm. https://github.com/memorysafety/rav1d/issues/1294 https://github.com/memorysafety/rav1d/issues/1294
- tuetuopay 1y ago
  There seems to be multiple people at videolan dunking on rav1d, in notable part due to how it was done (transpile C to Rust, and cleanup afterwards). Perhaps they're Rust purists and don't think that's how it should have been done. Or perhaps they're not happy that rav1d proclaims that Rust is (almost) as fast as C when all the performance engineering efforts went in the ASM bits, that were copied verbatim from dav1d. My best guess would be for the same reasons the ffmpeg twitter account has shown a lot of vitriol too: funding taken away from the original project towards another effort.
mmastrac 1y ago
Rust allows for manual struct layout with #[repr(C)] (with some limits, but rav1d uses it heavily - https://github.com/search?q=repo%3Amemorysafety%2Frav1d%20%22repr(c)%22&type=code https://github.com/search?q=repo%3Amemorysafety%2Frav1d%20%2...), so some of this could likely be ported over to rav1d as well. I believe there's an occasional re-sync with the dav1d code, so it's entirely possible this ends up making both projects faster. You can see the struct the author of this PR modified here: https://github.com/memorysafety/rav1d/blob/main/include/dav1d/headers.rs#L949 https://github.com/memorysafety/rav1d/blob/main/include/dav1... Interesting tool linked by the author: https://linux.die.net/man/1/pahole https://linux.die.net/man/1/pahole
- tialaramex 1y ago
  It makes sense that rav1d would need a bunch of repr(C) because the initial conversion is just mindlessly derived from the C, so if there's C which just bit-copies part of a data structure this cannot possibly work in Rust unless we explicitly say "This structure needs to be laid out the same as in C". It also sounds as though at least some of this "speed up" was assuming dav1d doesn't need big integers where actually it does, but only for larger images. I can well imagine that DVD resolution works fine with 16-bit variables where the Ultra HD blows up nastily.
rowanG077 1y ago
It's so interesting that the author of this PR took the 3% slower than C as some kind of dis for rust. For me it was the opposite.
unlord 1y ago
Someone asked about benchmarks, so I ran these just now to bring data to the discussion: nathan@arm1:~/git/rav1d.new/target$ hyperfine --warmup 2 "release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8" Benchmark 1: release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8 Time (mean ± σ): 31.532 s ± 1.971 s [User: 244.512 s, System: 1.644 s] Range (min … max): 28.498 s … 34.270 s 10 runs nathan@arm1:~/git/dav1d.new/build$ hyperfine --warmup 2 "tools/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8" Benchmark 1: tools/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8 Time (mean ± σ): 29.696 s ± 2.308 s [User: 230.507 s, System: 1.479 s] Range (min … max): 26.618 s … 35.105 s 10 runs It shows that as of this moment rav1d is (31.532 - 29.696)/29.696 * 100 = 6.2% slower to decode this Netflix test sequence. Note, this is an improvement from the (32.775 - 29.696)/29.696 * 100 = 10.4% when Prossimo posted a bounty for improving rav1d [1]: nathan@arm1:~/git/rav1d.old/target$ hyperfine --warmup 2 "release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8" Benchmark 1: release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8 Time (mean ± σ): 32.775 s ± 2.694 s [User: 254.120 s, System: 1.659 s] Range (min … max): 28.847 s … 37.606 s 10 runs None of this is particularly new, I reported this gap in performance over a year ago [2]. Here are some questions for HN: Even if rav1d closes the gap, who will ship rav1d over dav1d? More than 85% of dav1d is hand written assembly that rav1d takes as-is and calls via unsafe blocks. Is this really memory safety? The dav1d improvements must continuously be backported to rav1d, see the 82 closed PR's here [3]. Who is going to pay for this maintenance in perpetuity? VideoLAN fuzzes dav1d and fixes bugs extremely quickly, typically less than 24h. The rav1d developers are Rust experts, but not codec experts. Is it reasonable to expect the same support? [1] https://www.memorysafety.org/blog/rav1d-perf-bounty/ https://www.memorysafety.org/blog/rav1d-perf-bounty/ [2] https://github.com/memorysafety/rav1d/issues/804 https://github.com/memorysafety/rav1d/issues/804 [3] https://github.com/memorysafety/rav1d/pulls?q=backport+is%3Aclosed+is%3Apr https://github.com/memorysafety/rav1d/pulls?q=backport+is%3A...
- StopDisinfo910 1y ago
  > Even if rav1d closes the gap, who will ship rav1d over dav1d? More than 85% of dav1d is hand written assembly that rav1d takes as-is and calls via unsafe blocks. Is this really memory safety? > The dav1d improvements must continuously be backported to rav1d, see the 82 closed PR's here [3]. Who is going to pay for this maintenance in perpetuity? No one? Isn't the point of rav1d to show that it's possible to write a performant encoder in semi-idiomatic Rust and that it doesn't have to be very different from one written in C? It seemed pretty clear to me that rav1d was supposed to be a fun "research" side-project from its author shared with everyone and with an unclear future which will depends of what the community wants to actually do with it but I might be completely wrong.

50 points by ycomb_anon 1y ago

Testing has not been fully completed yet, but if PR merge. rav1d will become even more difficult to optimize. How much real data alignment helps? Wouldn't -O3 with -Ofast do all code optimization for programmer. Contributor dav1d claims 1-3% growth after his optimization, depending on video dataset payload. He nullified 1% optimization in rav1d, if the real growth was 3%, rav1d will not soon be able to equalize benchmark results. Another question in theory can Rust be faster than C? If all possible optimizations are applied.

refulgentis 1y ago
> Wouldn't -O3 with -Ofast do all code optimization for programmer. No? > Contributor dav1d claims 1-3% growth after his optimization, depending on video dataset payload. He nullified 1% optimization in rav1d, if the real growth was 3%, rav1d will not soon be able to equalize benchmark results. Aren't you the contributor? (You have a very unique writing voice) > Another question in theory can Rust be faster than C? If all possible optimizations are applied. I don't see why not? Other than that: A) Great work! B) Unsolicited advice, apologies: your technical acumen is being outshadowed by projection of motivations. They're just programming languages. There's no way to say one is definitely better than the other, and no guarantee one will be faster or slower than the other. Your forebears had similar arguments about C and assembler. Yet, neither of us is surprised to find there is no asmav1d. (and that's much more clean-cut of an argument w/r/t speed!) (I don't think it was the goal of a long-running FOSS project to advertise Rust is almost as fast as C when they offered a bounty)
pdimitar 1y ago
> Another question in theory can Rust be faster than C? If all possible optimizations are applied. Very likely not at this stage, and maybe not for years to come. But I'll take increased memory safety and elimination of entire class of bugs for 1-3% performance loss even on the most critical paths (with many actual wins for Rust in many other cases). While I do get what huge battery life implications might 5% differences in decoders make, I believe the current political climate mandates we use the most secure code we can and sacrifice smidgen bits of performance here and there for it. It was known for decades that at one point we'll have to roll up our sleeves and pay up the security tech debt. Sorry for the slightly philosophical message but I've no desire to comment on the actual tech details here.
- hulitu 1y ago
  > It was known for decades that at one point we'll have to roll up our sleeves and pay up the security tech debt. Yes, we are paying up the security tech debt. It is called "checklist security compliance". BTW, is there any rust project audited for security ?

brooke2k 1y ago

I don't understand the vitriol this author seems to have towards rav1d/Rust. It's just a separate implementation of the project. Slower, faster, who cares? Getting so attached to "which language is faster" seems a tad dramatic. But maybe I'm over-reading into what's actually friendly competition. The tone just seems oddly aggressive.

mmastrac 1y ago
I would guess the author is young and smart, but hasn't spent much time working with others. I've seen this in other developers with lots of potential. It usually takes a few years of mentorship to smooth the rough edges.
tgma 1y ago
[flagged]
Thaxll 1y ago
Well apparently the so called just 5% slower than dav1d is not true according to other benchmark, it's much slower.
- MallocVoidstar 1y ago
  What other benchmark?
  - ZeroGravitas 1y ago
    One of the dav1d team shared a benchmark on twitter suggesting that single core rav1d was about 6% slower than dav1d but multicore was 35% slower. https://nitter.net/rbultje/status/1924136075426951200 https://nitter.net/rbultje/status/1924136075426951200 But the rav1d project has 8 core benchmarks on their GitHub suggesting more like 8-10% slower on arm. https://github.com/memorysafety/rav1d/issues/1294 https://github.com/memorysafety/rav1d/issues/1294
tuetuopay 1y ago
There seems to be multiple people at videolan dunking on rav1d, in notable part due to how it was done (transpile C to Rust, and cleanup afterwards). Perhaps they're Rust purists and don't think that's how it should have been done. Or perhaps they're not happy that rav1d proclaims that Rust is (almost) as fast as C when all the performance engineering efforts went in the ASM bits, that were copied verbatim from dav1d. My best guess would be for the same reasons the ffmpeg twitter account has shown a lot of vitriol too: funding taken away from the original project towards another effort.

mmastrac 1y ago

Rust allows for manual struct layout with #[repr(C)] (with some limits, but rav1d uses it heavily - https://github.com/search?q=repo%3Amemorysafety%2Frav1d%20%22repr(c)%22&type=code https://github.com/search?q=repo%3Amemorysafety%2Frav1d%20%2...), so some of this could likely be ported over to rav1d as well. I believe there's an occasional re-sync with the dav1d code, so it's entirely possible this ends up making both projects faster. You can see the struct the author of this PR modified here: https://github.com/memorysafety/rav1d/blob/main/include/dav1d/headers.rs#L949 https://github.com/memorysafety/rav1d/blob/main/include/dav1... Interesting tool linked by the author: https://linux.die.net/man/1/pahole https://linux.die.net/man/1/pahole

tialaramex 1y ago
It makes sense that rav1d would need a bunch of repr(C) because the initial conversion is just mindlessly derived from the C, so if there's C which just bit-copies part of a data structure this cannot possibly work in Rust unless we explicitly say "This structure needs to be laid out the same as in C". It also sounds as though at least some of this "speed up" was assuming dav1d doesn't need big integers where actually it does, but only for larger images. I can well imagine that DVD resolution works fine with 16-bit variables where the Ultra HD blows up nastily.

rowanG077 1y ago

It's so interesting that the author of this PR took the 3% slower than C as some kind of dis for rust. For me it was the opposite.

unlord 1y ago

Someone asked about benchmarks, so I ran these just now to bring data to the discussion: nathan@arm1:~/git/rav1d.new/target$ hyperfine --warmup 2 "release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8" Benchmark 1: release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8 Time (mean ± σ): 31.532 s ± 1.971 s [User: 244.512 s, System: 1.644 s] Range (min … max): 28.498 s … 34.270 s 10 runs nathan@arm1:~/git/dav1d.new/build$ hyperfine --warmup 2 "tools/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8" Benchmark 1: tools/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8 Time (mean ± σ): 29.696 s ± 2.308 s [User: 230.507 s, System: 1.479 s] Range (min … max): 26.618 s … 35.105 s 10 runs It shows that as of this moment rav1d is (31.532 - 29.696)/29.696 * 100 = 6.2% slower to decode this Netflix test sequence. Note, this is an improvement from the (32.775 - 29.696)/29.696 * 100 = 10.4% when Prossimo posted a bounty for improving rav1d [1]: nathan@arm1:~/git/rav1d.old/target$ hyperfine --warmup 2 "release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8" Benchmark 1: release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8 Time (mean ± σ): 32.775 s ± 2.694 s [User: 254.120 s, System: 1.659 s] Range (min … max): 28.847 s … 37.606 s 10 runs None of this is particularly new, I reported this gap in performance over a year ago [2]. Here are some questions for HN: Even if rav1d closes the gap, who will ship rav1d over dav1d? More than 85% of dav1d is hand written assembly that rav1d takes as-is and calls via unsafe blocks. Is this really memory safety? The dav1d improvements must continuously be backported to rav1d, see the 82 closed PR's here [3]. Who is going to pay for this maintenance in perpetuity? VideoLAN fuzzes dav1d and fixes bugs extremely quickly, typically less than 24h. The rav1d developers are Rust experts, but not codec experts. Is it reasonable to expect the same support? [1] https://www.memorysafety.org/blog/rav1d-perf-bounty/ https://www.memorysafety.org/blog/rav1d-perf-bounty/ [2] https://github.com/memorysafety/rav1d/issues/804 https://github.com/memorysafety/rav1d/issues/804 [3] https://github.com/memorysafety/rav1d/pulls?q=backport+is%3Aclosed+is%3Apr https://github.com/memorysafety/rav1d/pulls?q=backport+is%3A...

StopDisinfo910 1y ago
> Even if rav1d closes the gap, who will ship rav1d over dav1d? More than 85% of dav1d is hand written assembly that rav1d takes as-is and calls via unsafe blocks. Is this really memory safety? > The dav1d improvements must continuously be backported to rav1d, see the 82 closed PR's here [3]. Who is going to pay for this maintenance in perpetuity? No one? Isn't the point of rav1d to show that it's possible to write a performant encoder in semi-idiomatic Rust and that it doesn't have to be very different from one written in C? It seemed pretty clear to me that rav1d was supposed to be a fun "research" side-project from its author shared with everyone and with an unclear future which will depends of what the community wants to actually do with it but I might be completely wrong.