[HN Gopher] Improving performance of original dav1d video decoder
       ___________________________________________________________________
        
       Improving performance of original dav1d video decoder
        
       Author : ycomb_anon
       Score  : 15 points
       Date   : 2025-05-24 23:24 UTC (1 days ago)
        
 (HTM) web link (code.videolan.org)
 (TXT) w3m dump (code.videolan.org)
        
       | ycomb_anon wrote:
       | 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 wrote:
         | > 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)
        
       | brooke2k wrote:
       | 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 wrote:
         | 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.
        
       | mmastrac wrote:
       | 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%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/dav1...
       | 
       | Interesting tool linked by the author:
       | https://linux.die.net/man/1/pahole
        
       ___________________________________________________________________
       (page generated 2025-05-26 23:00 UTC)