Announcement

Collapse
No announcement yet.

Rav1e 0.5 Beta Released For This Rust-Written AV1 Encoder

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    RedEyed
    Senior Member

  • RedEyed
    replied
    Originally posted by mdedetrich View Post

    The former is being worked on, not sure about the latter since streams opens up a massive can of worms especially in a language like Rust that is strongly typed

    For those wondering how Rust programs can end up beating C equivalents, one of the things that Rust allows is fearless concurrency and memory safety. Although C theoretically speaking can be just as fast as Rust, due how terrible it is in handling concurrency as well memory safety issues a lot of people end up coding in a style that is very conservative/fearful due to how easy it is to make hard to track bugs.

    When you have a tool that mathematically validates data flow (which is what Rust's linear type system is essentially proving), you can go completely crazy adding in optimizations (such as multi threading) without needing to worry about race conditions and continue working on such codebases without fear of regressions.

    No Rust doesn't magically solve all logic bugs, but it makes a portion of them impossible which means you can spend the gained time/effort in other areas.
    AFAIR C99 doesn't define thread and it doesn't have any memory issues.
    All issues come from programmers, because everything (almost) in C is manual which gives you great control but is very error prone.

    C is lower level than Rust, but both languages are made for low level programming.
    I think, that a good analogy would be a comparison of assembler with C, and C with Rust

    C is better than assembler in all cases except theoretical performance, and was designed to replace it
    Rust is better than C in all cases except theoretical performance, and was designed to replace it
    RedEyed
    Senior Member
    Last edited by RedEyed; 10 August 2021, 02:20 AM.

    Leave a comment:

  • blackshard
    Senior Member

  • blackshard
    replied
    Originally posted by mdedetrich View Post
    Although C theoretically speaking can be just as fast as Rust
    Maybe it is the opposite: C is lower level than Rust, at most Rust has to catch up (at most).


    Originally posted by mdedetrich View Post
    Although C theoretically speaking can be just as fast as Rust, due how terrible it is in handling concurrency as well memory safety issues a lot of people end up coding in a style that is very conservative/fearful due to how easy it is to make hard to track bugs.
    C does not handle concurrency in any way, does it?
    The programmer has to do all the burden of handling concurrency and memory sharing.
    Rust does it at the highest level, enforcing the programmer does not make such mistakes at all. The programmer is freed of thinking about manually handling such tasks, but on the opposite has a stricter programming language logic.

    Despite the purpose of C and Rust is the same, they are very different beasts.

    Leave a comment:

  • bug77
    Senior Member

  • bug77
    replied
    Originally posted by uid313 View Post
    Rust is really nice for decoders, interpreters, and parsers thanks to things such as Option<T>, Result<T, E>, and the match statement.

    But I am frustrated with Rust's lack of support for declaring async functions in traits and lack of async streams. 😢
    It makes it difficult to share code by creating a function that takes in either UnixListener or a TcpListener as argument, or a function that takes in either a UnixStream and TcpStream as argument.
    Yes, no language offers all the constructs ever invented. And even if it did, you'd be complaining it takes ages to compile, right?

    To me, Rust was surprisingly productive, even if my background is not C or C++. It's not one of the languages that are not easy on the eyes though. Then again, the same was said about C code, back in the day: "it's meant to be run, not read".
    bug77
    Senior Member
    Last edited by bug77; 10 August 2021, 02:59 AM.

    Leave a comment:

  • mdedetrich
    Senior Member

  • mdedetrich
    replied
    Originally posted by uid313 View Post

    But I am frustrated with Rust's lack of support for declaring async functions in traits and lack of async streams. 😢
    It makes it difficult to share code by creating a function that takes in either UnixListener or a TcpListener as argument, or a function that takes in either a UnixStream and TcpStream as argument.
    The former is being worked on, not sure about the latter since streams opens up a massive can of worms especially in a language like Rust that is strongly typed

    For those wondering how Rust programs can end up beating C equivalents, one of the things that Rust allows is fearless concurrency and memory safety. Although C theoretically speaking can be just as fast as Rust, due how terrible it is in handling concurrency as well memory safety issues a lot of people end up coding in a style that is very conservative/fearful due to how easy it is to make hard to track bugs.

    When you have a tool that mathematically validates data flow (which is what Rust's linear type system is essentially proving), you can go completely crazy adding in optimizations (such as multi threading) without needing to worry about race conditions and continue working on such codebases without fear of regressions.

    No Rust doesn't magically solve all logic bugs, but it makes a portion of them impossible which means you can spend the gained time/effort in other areas.

    Leave a comment:

  • uid313
    Senior Member

  • uid313
    replied
    Rust is really nice for decoders, interpreters, and parsers thanks to things such as Option<T>, Result<T, E>, and the match statement.

    But I am frustrated with Rust's lack of support for declaring async functions in traits and lack of async streams. 😢
    It makes it difficult to share code by creating a function that takes in either UnixListener or a TcpListener as argument, or a function that takes in either a UnixStream and TcpStream as argument.

    Leave a comment:

  • oleid
    Senior Member

  • oleid
    replied
    when it comes to performance we've generally found SVT-AV1 to be faster at this point in time.
    Is this still true if you consider FPS at given picture quality?

    Leave a comment:

  • phoronix
    Administrator

  • Rav1e 0.5 Beta Released For This Rust-Written AV1 Encoder

    Phoronix: Rav1e 0.5 Beta Released For This Rust-Written AV1 Encoder

    Audio/video encoders and decoders are one of the areas where usage of the Rust programming language has increasing interest for speed and safety. One of the most promising Rust-written encoders at the moment is Rav1e for AV1 video encoding and it's now working towards its v0.5 release...

    https://www.phoronix.com/scan.php?pa...Rav1e-0.5-Beta
Working...
X