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)

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.

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.

You sometimes get contributors which are very attached to their work and have strong feelings about how things should be done with the deadly combo of low / still developing social skills.

This is their rationale, which you might disagree with, but I can’t notice any “vitriol” you’re talking about. Other people might have different opinions than yours about their favourite language, and that’s fine.

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.

> 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.

Can you share what system was used (ARM CPU, OS, etc.)?

so basically the work is done in dav1d, but claimed in rav1d.

It really makes rust look like a parasite.