Rust-Based, Memory-Safe PNG Decoders "Vastly Outperform" C-Based PNG Libraries

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67114

    Rust-Based, Memory-Safe PNG Decoders "Vastly Outperform" C-Based PNG Libraries

    Phoronix: Rust-Based, Memory-Safe PNG Decoders "Vastly Outperform" C-Based PNG Libraries

    Video and image encoders/decoders written in the Rust programming language for its memory safety guarantees is often viewed as one of the compelling areas for the programming language to better protect against malformed/malicious content especially within web browsers. Not only are Rust-based PNG image decoders proving to be more secure than C-based decoders, but the performance of the Rust solutions can be even faster...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • Volta
    Senior Member
    • Apr 2019
    • 2237

    #2
    Not only are Rust-based PNG image decoders proving to be more secure than C-based decoders
    Where?

    but the performance of the Rust solutions can be even faster.
    They're only faster, because support the latest optimizations. Performance of C solutions can be the fastest.

    Comment

    • FreezyLemon
      Junior Member
      • Oct 2024
      • 1

      #3
      I remember some similar news about the Rust cryptography libraries (rustls I think) being faster than their C counterparts, and then it turned out the tested configuration used a Rust wrapper (aws-lc-rs) around a C library for at least some of the real logic.

      I recognize these decoder crates though and AFAIK, these are "real" Rust implementations, so this is nice to see. I wish we had more Rust implementations of video codecs too, though...

      Comment

      • Britoid
        Senior Member
        • Jul 2013
        • 2156

        #4
        Not only are Rust-based PNG image decoders proving to be more secure than C-based decoders​
        Of course a library that's nearly 30 years old and used widely in production is going to be slower and have more CVEs than a rarely used relatively new library which can avoid 30 years of technical debt and target modern hardware.

        Rust won't save you from logic failures or stupid developers.

        Comment

        • reba
          Senior Member
          • May 2020
          • 672

          #5
          Originally posted by Volta View Post
          They're only faster, because support the latest optimizations. Performance of C solutions can be the fastest.
          Nothing beats handcrafted Assembler. C is just ugly bloat. Professionals do not need excellent tooling modern languages provide. These people just piss excellence.

          Comment

          • Shnatsel
            Senior Member
            • Jan 2012
            • 142

            #6
            By the way, you don't have to use Rust to get memory-safe image decoding. WUFFS achieves memory safety and compiles down to C, and it's basically tied with Rust decoders in benchmarks: https://github.com/google/wuffs/

            The WUFFS GIF decoder has been used in Chromium in production for a few years now.

            Comment

            • skeevy420
              Senior Member
              • May 2017
              • 8553

              #7
              That headline is kind of misleading. Only 2 of 3 are written with Rust.

              It brought out the Rust people faster than the speed of light so I suppose it's doing its job

              Comment

              • zexelon
                Senior Member
                • May 2019
                • 739

                #8
                Bad news and Rust news are the most powerful proof we have of FTL travel...

                Comment

                • V1tol
                  Senior Member
                  • May 2016
                  • 603

                  #9
                  Originally posted by Volta View Post
                  They're only faster, because support the latest optimizations. Performance of C solutions can be the fastest.
                  Where is the argument about superior compiler flags like -O3, -march=native and millions of others? Oh yes, sometimes they introduce bugs because of undefined behavior and other marvels of C that make bad software even worse. And in 2024 we are still compiling software with -O2 and afraid to even use -v3 architecture subset in production which is already 10 years old.

                  Originally posted by Britoid View Post
                  Of course a library that's nearly 30 years old and used widely in production is going to be slower and have more CVEs than a rarely used relatively new library which can avoid 30 years of technical debt and target modern hardware.
                  I wonder why nobody wrote a new library with latest optimizations and without technical debt in C. Oh yes, because they can't and probably nobody can do that. Google even decided that it is simpler to create a new specific language for decoders to write a library just to avoid using great and marvelous C directly.

                  Originally posted by Britoid View Post
                  Rust won't save you from logic failures or stupid developers.
                  You surely know such a language, you don't mind sharing with everyone?​ I wonder what language saves from constructs like if (true) { exit(1); } (where true is of course some result of complex long computation task).

                  Comment

                  • chuckula
                    Senior Member
                    • Dec 2011
                    • 842

                    #10
                    So this isn't really an advertisement for RUST, it's an advertisement for AVX256 & AVX512. Which I do like, but let's not conflate things.

                    Additionally, if the RUST implementation requires me to download 8GB of "crates" to decode a PNG, I'm not sure it's actually good.

                    Comment

                    Working...
                    X