Rust does not bring more performance. Just more safety.

The way they weave these instructions can be very hard to express with a high level language.

Further, there's a ton of work with arrays and importantly parts of arrays. They can, for example, need to extract every other element up to 1/2 the array. Unfortunately, rust has runtime array bounds checks which make writing that sort of code slower. The compiler can elade those checks, but usually only in simple cases.

The authors would be writing a bunch of unsafe rust to get the performance they want and rust makes that more painful on purpose.

I like rust, but C/ASM really is the right choice here. This is one of the few cases where rust's safety is a major detriment.

If you can stand Lex Friedman for a bit, the VLC authors talk about why you use ASM for a video decoder instead of pure C or rust.

it's not much slower than the original C/ASM implementation (last i checked ~5%?) but that matters here

https://code.videolan.org/videolan/dav2d/-/blob/main/src/dat...

There is a project to write an AV1 decoder in Rust: Rav1d (really stretching the name here).

https://github.com/memorysafety/rav1d

They got within 5% of the performance of dav1d and held a contest to close the gap but I think I read somewhere that this wasn't achieved.

https://www.memorysafety.org/blog/rav1d-perf-bounty/

They claimed

> This is enough of a difference to be a problem for potential adopters, and, frankly, it just bothers us.

But in my opinion nobody actually cares about 5% in absolute terms. It's likely just Rust naysayers using that as an excuse.

I think the likely reason for dav2d using C is that they can reuse lots of code and infrastructure from dav1d. But I agree it would be much better if they worked on Rav2d instead (these names!). You can hardly complain about a 5% overhead if you're opting in to 5x more decoding complexity.