News for hackers. Stuff that matters.
Re:Improving performance of original dav1d video decoder by brooke2k on Monday May 26, 2025 @06:26PM (#44102249)
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.

Re:Improving performance of original dav1d video decoder by mmastrac on Monday May 26, 2025 @06:41PM (#44102324)
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.
Re:Improving performance of original dav1d video decoder by Thaxll on Monday May 26, 2025 @07:31PM (#44102606)
Well apparently the so called just 5% slower than dav1d is not true according to other benchmark, it's much slower.
Re:Improving performance of original dav1d video decoder by MallocVoidstar on Monday May 26, 2025 @08:54PM (#44102994)
What other benchmark?
Re:Improving performance of original dav1d video decoder by ZeroGravitas on Tuesday May 27, 2025 @01:16PM (#44108867)
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

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

Re:Improving performance of original dav1d video decoder by tuetuopay on Monday May 26, 2025 @10:05PM (#44103312)
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.

Re:Improving performance of original dav1d video decoder by viraptor on Tuesday May 27, 2025 @12:06AM (#44103879)
> funding taken away from the original project towards another effort

Alternative phrasing: "funding originally applied to one project benefiting multiple efforts". It's sad to see people from open source doing... gatekeeping? jealousy? something...

Re:Improving performance of original dav1d video decoder by blub on Tuesday May 27, 2025 @01:25AM (#44104145)
Alternative definition of outsourcing: the salary originally applied to one person in high cost country benefiting multiple people in low cost country :)

But… why high cost country developers jealous?

Re:Improving performance of original dav1d video decoder by hitekker on Wednesday May 28, 2025 @06:40PM (#44121269)
> 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.

This is key. Not to mention how advocates for ra1vd are gaming their benchmarks and obscuring how unsafe the actual code is. The bounty presenting it as "safe" on memorysafety.org is a laugh.

IMO, that dishonesty deserves some snark from VLC and ffmpeg.

Re:Improving performance of original dav1d video decoder by viraptor on Tuesday May 27, 2025 @12:36AM (#44103973)
It definitely is oddly aggressive. They could just say that the rav1d bounty motivated them to look for improvements in dav1d and it would be an awesome result. There's nothing like healthy friendly competition. But this isn't it.
Re:Improving performance of original dav1d video decoder by StopDisinfo910 on Tuesday May 27, 2025 @06:22AM (#44105539)
I think the ffmpeg / libav controversy definitely showed that codec implementation is an area which doesn't attract only well adjusted people. Emulators have the same issue. It seems to be common about this very technical, very low level projects.

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.

Re:Improving performance of original dav1d video decoder by sph on Tuesday May 27, 2025 @08:28AM (#44106275)
> making tools for more convenient work with C/C++ projects on Rust (as Python) is a more useful thing than trying to replace an already working dav1d solution (or any FOSS infrastructure) that has been tested by time, many contributors and most vulnerabilities have been closed. New projects will also have performance and vulnerability issues. No need to waste your time writing another bike, there are much more useful things.

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.