Rav1e Squeezes Out More Performance For This Rust-Written AV1 Encoder

[schmidtbag]

My thoughts on "safest":

In the context of languages with close-to-metal access, Rust is widely regarded as the safest way to write close-to-metal code when doing programming-in-the-large. Do you have evidence to the contrary? Which other language would you suggest using instead of Rust if the overarching goal is to use a language with facilities to promote and support memory safety in close-to-metal code? Ada?

No of course I don't have evidence to the contrary, and I never implied otherwise. How have I not made it clear that I don't have a problem with them using Rust? I must've said/implied at least 5 times already that there's nothing wrong with them using Rust (and now 6).
Regardless, if that's the safest solution, wouldn't that mean their usage of assembly is compromising that safety, especially given how it's handling very low-level functions?

My thoughts on "fastest":

In the specific examples where certain CPUs offer specialised instructions (and Rust hasn't yet grown support for generating assembly code that is just as fast), it seems to me that it would make sense to try to use Rust's unsafe and macro facilities to embed these localised pieces of code into the larger Rust code base.

If you disagree with this approach, ok. It's not my job to convince you that the chosen approach is sound, but as you yourself state, the developers of Rav1e aren't likely aren't stupid so it stands to reason that they will have considered the trade-offs? But perhaps you don't think they have and want someone to confirm that for you? If so, why don't you just contact them and ask them and get the relevant information from the horse's mouth so to speak?

I don't know their exact approaches or priorities, and therefore don't know what tradeoffs they may or may not have. This is why I keep saying I don't have a problem with what they're doing, because I don't know better. Frankly, this isn't really that big of a deal to me; it's merely just something that caught my eye. My entire thought process can be summed up as:
It's strange (not bad) to me they chose to do a very difficult part of their coding in a difficult language, where the ostensibly easier part is done in an easier language. It's perfectly normal for something to seem odd on the surface, but makes total sense once you dive deeper into it.
As for asking them, I could probably figure out the answer myself if I investigated the source code. Seeing as I don't have the interest/patience to do that, I don't feel I have the right to waste their time with petty curiosities. I can say with confidence they know what they're doing more than me, so it's not like anything I have to say to them has any value.

In light of the above hypothesis, I don't suppose you would consider re-evaluating your question of why rav1e isn't just written entirely in assembly? What benefits (if any) would doing so have compared to the current approach when taking into account the 'safe' goal?

In light of your hypothesis, yes, I would consider re-evaluating my question.
Despite the scc results, we still don't know what constraints they have, so, I don't have a way to answer what benefits they would have if they took an alternate route. Again: I didn't say the route they took was bad. It's arguably not the best, but the key word there is "arguably". Not like "best" really matters, either. I personally don't expect perfection.

[milkylainen]

What's the point of writing it in C if you're just going to use raw assembly in the core loops anyways?

That statement can be said of any low-level language

Sure. But then you can hardly claim that "it's faster because omgbbq RUST!"

[Orphis]

It is easy enough to test a few localized functions fully for safety in general. So you can run a fuzzer and various sanitizers on those assembly optimized functions AND on the general algorithm to find programming errors. It works just fine.

[bachchain]

Ah ok. Fair enough. Though honestly, I think anyone with the skills to successfully write in assembly is going to have the competence to avoid stuff like segfaults.

"If we just hired better programmers, then bugs would never happen".
Worked out well for the zero times it's actually worked

[timofonic]

I know you're being facetious but seriously, why not write everything in pure assembly? zamadatix makes a good point - if some of the most important and [presumably] difficult part of your code is already written in such a low-level language, why stop there? Or, why Rust, as opposed to any other high[er]-level language?

Think of it like this:
Let's say you're building your own car engine. You spend a lot of time and resources developing it, perfecting its efficiency and power. And then... you settle with an off-the-shelf 4-speed manual transmission. It's not that the transmission is bad - you're still getting direct drive of the motor, and at least you're not pairing it with some crappy 70s slushbox automatic. But it isn't the best thing to pair it with either and it seems like such an odd place to suddenly take take things easy, so some would wonder "why didn't you make the transmission too?".

EDIT:
I get that Rust is meant to be safer, but, what kind of incriminating data are you going to collect out of encoding an AV1 video?

Please publish something complex in GitHub in 100% assembly.

[schmidtbag]

"If we just hired better programmers, then bugs would never happen".
Worked out well for the zero times it's actually worked

You say that as though there is nothing out there that is bug-free, or that Rust can magically fix all of your problems.

[dwagner]

The whole coverage on "how fast is AV1 encoder X" is still pointless without a thorough consideration of the resulting quality at certain bitrates.

[archsway]

It's strange (not bad) to me they chose to do a very difficult part of their coding in a difficult language, where the ostensibly easier part is done in an easier language. It's perfectly normal for something to seem odd on the surface, but makes total sense once you dive deeper into it.

It's not really that assembly is difficult to program in; more that you have to do everything yourself with no compiler to check you - from experience, many bugs in assembly are just stupid things like forgetting to return from a function or copying the wrong amount of data, which will happen more often in the "easy" parts of the code.

Also, the Rav1e devs (I assume) first implement a "generic" Rust version of a function, and then write assembly versions of that function. Because there is another version of the function, it is easy to fuzz both of them to verify they do the same thing, making new bugs less likely.

There's no point in doing that for non performance critical code because when you already have a working Rust version why would you want to rewrite it in assembler (and introduce more bugs)?

[smitty3268]

You say that as though there is nothing out there that is bug-free, or that Rust can magically fix all of your problems.

Perfect is the enemy of good.

[smitty3268]

It's strange (not bad) to me they chose to do a very difficult part of their coding in a difficult language, where the ostensibly easier part is done in an easier language.

I haven't actually reviewed the code myself, but I think this is a fundamental misunderstanding of how these projects typically work. The assembly code is usually very carefully architected to work on simple discrete chunks of data without any complicated logic like handling of global state, threading, etc. which is where bugs typically come into play.

An I/O parser, threading logic, and memory management is where the complicated code is and that's what (presumably) Rust handles, or C in another codec. The assembly code is the easy part, just looping over an array of data and performing some mathematical calculations on it.