5 ms·

> Our Rust-based rav1d decoder is currently about 5% slower than the C-based dav1d decoder (the exact amount differs a bit depending on the benchmark, input, an

> Our Rust-based rav1d decoder is currently about 5% slower than the C-based dav1d decoder (the exact amount differs a bit depending on the benchmark, input, and platform). This is enough of a difference to be a problem for potential adopters I'm really surprised that a 5% performance degradation would lead people to choose C over Rust, especially for something like a video codec. I wonder if they really care or if this is one of those "we don't want to use Rust because of silly reasons and here's are reasonable-sounding but actually irrelevant technical justification"...

VWWHFSfQ 2y ago
I think latency sensitive applications will usually prefer better performance and deal with safety issues, as opposed to better safety and deal with performance issues. So I doubt it's any religious thing between c and Rust.
- viraptor 2y ago
  It's also a big difference in your environment. A desktop with spare power, decoding a video from an untrusted source? You probably want the safe version. A farm of isolated machines doing batch transcoding jobs? Give me every single % improvement you can. They can get completely owned and still won't be able to access anything useful or even reach out to the network. A crash/violation will be registered and a new batch will get a clean slate anyway.
  - gafferongames 2y ago
    I think you're taking the term "safety" in rust a bit too literally. It's got bounds checking in it man. That's all. You can also write totally safe programs in C, or if you really want to be serious about it, write the program in F and use formal verification like this crypto library does: https://github.com/hacl-star/hacl-star https://github.com/hacl-star/hacl-star
    - viraptor 2y ago
      > It's got bounds checking in it man. That's all. It's got bounds checking, lifetimes, shared access checks, enforced synchronisation, serious typed enums (not enforced but still helpful), explicit overflow behaviour control, memory allocation management, etc. etc. to help with safety. Far from "that's all". > You can also write totally safe programs in C, No you can't beyond trivial levels in practice. Even super human exceptions like DJB made mistakes and statistically nobody here is even close to DJB. > use formal verification like this crypto library does "Beware of bugs in the above code; I have only proved it correct, not tried it." -D.Knuth (That is - you can make mistakes in the spec too - see how many issues the verified sel4 had https://github.com/seL4/seL4/blob/master/CHANGES.md https://github.com/seL4/seL4/blob/master/CHANGES.md )
    - imtringued 2y ago
      If you are willing to use formal verification you can just turn off the bound checks in production so I don't get your point. Also, dismissing bounds checking as "just bounds checking" shows how delusional you are.
- rand_r 2y ago
  Yes, exactly. Latency is the killer feature. Doing a video call with extra 50ms of latency is noticeable.
lgl 2y ago
I may be wrong but if you're one of the "big guys" doing video then a 5% performance difference probably translates into millions of $ in the CPU/GPU bill
- viraptor 2y ago
  Projects like zencoder https://www.brightcove.com/products/zencoder/ https://www.brightcove.com/products/zencoder/ can definitely save $$$ daily on a 5% improvement. It's pure profit for them.
- IshKebab 2y ago
  Right but this is a software decoder, not an encoder. No-one is running it at scale.
  - degamad 1y ago
    No-one is decoding video at scale? Video transcribing services? LLM training?
topspin 2y ago
Developers fight tooth and nail to get every bit of performance from video codecs because this goes directly to battery life and heat on a scale of billions of devices. You can't handwave a 5% performance drop as if this is some recipe app. People pour over microamp power analyzers and high resolution thermographs because they "really care."
- 0x000xca0xfe 2y ago
  Not to mention that 5% in decoding can make the difference between "flawless playback" and "random stutters and frame drops" on some devices. See also: Gamers ready to shell out $$$ because of 1% lows.
  - topspin 2y ago
    About the only thing I imagine receives greater attention in terms of optimization than video codecs is cellular modems.
bArray 2y ago
I can think of a few use cases: 1. Desktop - If both implementations run the same but one is faster, you run the faster one to stop the decode spluttering on those borderline cases. 2. Embedded - Where resources are limited, you still go for the faster one, even if it might one day leas to a zero day because you've weighed up the risk and reducing the BOM is an instant win and trying to factor in some unknown code element isn't. 3. Server - You accept media from unknown sources, so you are sandboxed anyway. Losing 5% of computing resources adds up to big $ over a year and at enough scale. At Youtube for example it could be millions of dollars a year of compute doing a decode and then re-encode. Some other resistances: 1. Energy - If you have software being used in many places over the world, that cost saving is significant in terms of energy usage. 2. Already used - If the C implementation is working without issue, there would be high resistance to spend engineering time to put a slower implementation in. 3. Already C/C++ - If you already have a codebase using the same language, why would you now include Rust into your codebase? 4. Bindings - Commonly used libraries use the C version and are slow to change. The default may remain the C version in the likes of ffmpeg.
- tcfhgj 2y ago
  > 3. Server - You accept media from unknown sources, so you are sandboxed anyway. Losing 5% of computing resources adds up to big $ over a year and at enough scale. At Youtube for example it could be millions of dollars a year of compute doing a decode and then re-encode. I wish big tech had to pay all the electron garbage they produce
  - bArray 2y ago
    You mean the electron app? I agree, I understand the problem they try to fix but it is such a garbage way of producing software. I have to have Discord running for some projects, and it is heavy as hell.
Ragnarork 2y ago
> I'm really surprised that a 5% performance degradation would lead people to choose C over Rust I'm really surprised that because something is in Rust and not in C, it would lead people to ignore a 5% performance degradation. Seriously... when you get something that's 5% faster especially in the video codec space, why would you dismiss it just because it's not in your favorite language... That does sound like a silly reason to dismiss a faster implementation.
- edude03 2y ago
  > just because it's not in your favorite language. Kind of a strawman argument though. The question is, is the 5% difference (today) worth the memory safety guaranties? IE, would you be OK if your browser used 5% more power displaying video, if it meant you couldn't be hacked via a memory safety bug.
  - mvanbaak 2y ago
    No, it wouldn't Because it also means your battery drains 5% faster, it gets hotter, you will need to upgrade your media player device etc etc etc. Seen on the scale of the actual deployment, this is HUGE.
    - viraptor 2y ago
      And yet we collectively got a bigger hit across the board with the speculative exploit mitigations. We made that choice and we'll make it again.
  - Ragnarork 2y ago
    I can agree on the strawman but parent I responded to was mentioning "silly reasons" for not choosing a Rust implementation over a C one. A 5% performance difference in that space is anything but a silly reason. Also glancing over the implementation of rav1d, it seems to have some C dependencies, but also unsafe code in some places. This to me makes banging the drum of memory safety - as it is often done whenever a Rust option is discussed, for obvious reasons since it's one of the main selling point of the language - a bit moot here.
Benjamin_Dobell 2y ago
> especially for something like a video codec Why especially video decoders? > I wonder if they really care or if this is one of those "we don't want to use Rust because of silly reasons and here's are reasonable-sounding but actually irrelevant technical justification"... I would have thought video decoders are specifically one of the few cases where performance really is important enough to trump language guaranteed security. They're widely deployed, and need to work in a variety of environments; everything from low power mobile devices to high-throughput cloud infrastructure. They also need to be low latency for live broadcast/streaming. That's not to say security isn't a concern. It absolutely is, especially given the wide variety of deployment targets. However, video decoders aren't something that necessarily need to continually evolve over time. If you prioritize secure coding practices and pair that with some formal/static analysis, then you ought to be able to squeeze out more performance than Rust. For example, Rust may be inserting bounds checks on repeated access — where as a C program could potentially validate this sort of information just the once up front and pass the "pre-validated" data structure around (maybe even across threads) "knowing" that it's valid data. Yes, there's a security risk involved, but it may be worth it.
- steveklabnik 2y ago
  Not your parent, but video codecs are basically handling untrusted input from a user, and are therefore the sorts of programs that have a good justification for increased safety. You're also right that performance is paramount. That's why it's non-trivial.
- IshKebab 2y ago
  > Why especially video decoders? Codecs are a very common source of security vulnerabilities.

VWWHFSfQ 2y ago

I think latency sensitive applications will usually prefer better performance and deal with safety issues, as opposed to better safety and deal with performance issues. So I doubt it's any religious thing between c and Rust.

viraptor 2y ago
It's also a big difference in your environment. A desktop with spare power, decoding a video from an untrusted source? You probably want the safe version. A farm of isolated machines doing batch transcoding jobs? Give me every single % improvement you can. They can get completely owned and still won't be able to access anything useful or even reach out to the network. A crash/violation will be registered and a new batch will get a clean slate anyway.
- gafferongames 2y ago
  I think you're taking the term "safety" in rust a bit too literally. It's got bounds checking in it man. That's all. You can also write totally safe programs in C, or if you really want to be serious about it, write the program in F and use formal verification like this crypto library does: https://github.com/hacl-star/hacl-star https://github.com/hacl-star/hacl-star
  - viraptor 2y ago
    > It's got bounds checking in it man. That's all. It's got bounds checking, lifetimes, shared access checks, enforced synchronisation, serious typed enums (not enforced but still helpful), explicit overflow behaviour control, memory allocation management, etc. etc. to help with safety. Far from "that's all". > You can also write totally safe programs in C, No you can't beyond trivial levels in practice. Even super human exceptions like DJB made mistakes and statistically nobody here is even close to DJB. > use formal verification like this crypto library does "Beware of bugs in the above code; I have only proved it correct, not tried it." -D.Knuth (That is - you can make mistakes in the spec too - see how many issues the verified sel4 had https://github.com/seL4/seL4/blob/master/CHANGES.md https://github.com/seL4/seL4/blob/master/CHANGES.md )
  - imtringued 2y ago
    If you are willing to use formal verification you can just turn off the bound checks in production so I don't get your point. Also, dismissing bounds checking as "just bounds checking" shows how delusional you are.
rand_r 2y ago
Yes, exactly. Latency is the killer feature. Doing a video call with extra 50ms of latency is noticeable.

lgl 2y ago

I may be wrong but if you're one of the "big guys" doing video then a 5% performance difference probably translates into millions of $ in the CPU/GPU bill

viraptor 2y ago
Projects like zencoder https://www.brightcove.com/products/zencoder/ https://www.brightcove.com/products/zencoder/ can definitely save $$$ daily on a 5% improvement. It's pure profit for them.
IshKebab 2y ago
Right but this is a software decoder, not an encoder. No-one is running it at scale.
- degamad 1y ago
  No-one is decoding video at scale? Video transcribing services? LLM training?

topspin 2y ago

Developers fight tooth and nail to get every bit of performance from video codecs because this goes directly to battery life and heat on a scale of billions of devices. You can't handwave a 5% performance drop as if this is some recipe app. People pour over microamp power analyzers and high resolution thermographs because they "really care."

0x000xca0xfe 2y ago
Not to mention that 5% in decoding can make the difference between "flawless playback" and "random stutters and frame drops" on some devices. See also: Gamers ready to shell out $$$ because of 1% lows.
- topspin 2y ago
  About the only thing I imagine receives greater attention in terms of optimization than video codecs is cellular modems.

bArray 2y ago

I can think of a few use cases: 1. Desktop - If both implementations run the same but one is faster, you run the faster one to stop the decode spluttering on those borderline cases. 2. Embedded - Where resources are limited, you still go for the faster one, even if it might one day leas to a zero day because you've weighed up the risk and reducing the BOM is an instant win and trying to factor in some unknown code element isn't. 3. Server - You accept media from unknown sources, so you are sandboxed anyway. Losing 5% of computing resources adds up to big $ over a year and at enough scale. At Youtube for example it could be millions of dollars a year of compute doing a decode and then re-encode. Some other resistances: 1. Energy - If you have software being used in many places over the world, that cost saving is significant in terms of energy usage. 2. Already used - If the C implementation is working without issue, there would be high resistance to spend engineering time to put a slower implementation in. 3. Already C/C++ - If you already have a codebase using the same language, why would you now include Rust into your codebase? 4. Bindings - Commonly used libraries use the C version and are slow to change. The default may remain the C version in the likes of ffmpeg.

tcfhgj 2y ago
> 3. Server - You accept media from unknown sources, so you are sandboxed anyway. Losing 5% of computing resources adds up to big $ over a year and at enough scale. At Youtube for example it could be millions of dollars a year of compute doing a decode and then re-encode. I wish big tech had to pay all the electron garbage they produce
- bArray 2y ago
  You mean the electron app? I agree, I understand the problem they try to fix but it is such a garbage way of producing software. I have to have Discord running for some projects, and it is heavy as hell.

Ragnarork 2y ago

> I'm really surprised that a 5% performance degradation would lead people to choose C over Rust I'm really surprised that because something is in Rust and not in C, it would lead people to ignore a 5% performance degradation. Seriously... when you get something that's 5% faster especially in the video codec space, why would you dismiss it just because it's not in your favorite language... That does sound like a silly reason to dismiss a faster implementation.

edude03 2y ago
> just because it's not in your favorite language. Kind of a strawman argument though. The question is, is the 5% difference (today) worth the memory safety guaranties? IE, would you be OK if your browser used 5% more power displaying video, if it meant you couldn't be hacked via a memory safety bug.
- mvanbaak 2y ago
  No, it wouldn't Because it also means your battery drains 5% faster, it gets hotter, you will need to upgrade your media player device etc etc etc. Seen on the scale of the actual deployment, this is HUGE.
  - viraptor 2y ago
    And yet we collectively got a bigger hit across the board with the speculative exploit mitigations. We made that choice and we'll make it again.
- Ragnarork 2y ago
  I can agree on the strawman but parent I responded to was mentioning "silly reasons" for not choosing a Rust implementation over a C one. A 5% performance difference in that space is anything but a silly reason. Also glancing over the implementation of rav1d, it seems to have some C dependencies, but also unsafe code in some places. This to me makes banging the drum of memory safety - as it is often done whenever a Rust option is discussed, for obvious reasons since it's one of the main selling point of the language - a bit moot here.

Benjamin_Dobell 2y ago

> especially for something like a video codec Why especially video decoders? > I wonder if they really care or if this is one of those "we don't want to use Rust because of silly reasons and here's are reasonable-sounding but actually irrelevant technical justification"... I would have thought video decoders are specifically one of the few cases where performance really is important enough to trump language guaranteed security. They're widely deployed, and need to work in a variety of environments; everything from low power mobile devices to high-throughput cloud infrastructure. They also need to be low latency for live broadcast/streaming. That's not to say security isn't a concern. It absolutely is, especially given the wide variety of deployment targets. However, video decoders aren't something that necessarily need to continually evolve over time. If you prioritize secure coding practices and pair that with some formal/static analysis, then you ought to be able to squeeze out more performance than Rust. For example, Rust may be inserting bounds checks on repeated access — where as a C program could potentially validate this sort of information just the once up front and pass the "pre-validated" data structure around (maybe even across threads) "knowing" that it's valid data. Yes, there's a security risk involved, but it may be worth it.

steveklabnik 2y ago
Not your parent, but video codecs are basically handling untrusted input from a user, and are therefore the sorts of programs that have a good justification for increased safety. You're also right that performance is paramount. That's why it's non-trivial.
IshKebab 2y ago
> Why especially video decoders? Codecs are a very common source of security vulnerabilities.