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

[phoronix]

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

Intel's SVT-AV1 video encoder for AV1 is currently the fastest AV1 CPU-based encoder we have seen but it's looking like in due time Rav1e could be closing in on it if they continue with their current trajectory...

http://www.phoronix.com/scan.php?page=news_item&px=Rav1e-Encoder-8-Titles-Speed

[zamadatix]

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

[skeevy420]

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

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

[grigi]

The point of using Rust, is that a large majority of your code is guaranteed to be "safe", so your area for dangerous code shrunk from 100% to, e.g. 10%.
It pretty much comes down to reducing cognitive load.

[timofonic]

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

You are right!

Let's write everything in pure assembly!

[bug77]

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

The point is you only have to care about safety for those pieces of code only. The compiler takes care of the rest.

[schmidtbag]

You are right!

Let's write everything in pure assembly!

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?

[ermo]

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?

AIUI, it is because assembly obscures the ideas you are trying to communicate to your fellow developers in favour of explicit control of hardware minutiae.

This is literally the reason why compilers were developed: To avoid having to write machine code directly, because it is too time consuming and cognitively taxing (and thus error prone) when humans are developing large software systems. Let's not forget that humans are the primary source of bugs in software.

Only in the specific cases where the trade-off of increased cognitive load is worth it in terms of raw performance does it make sense to write code directly in assembly. And even then, you typically hide the assembly behind a cognitive-load-lessening macro-invocation in the code so the preprocessor can substitute the assembly code into the higher-level source code at compile time.

EDIT: To answer your EDIT: Codecs have come under heavy scrutiny because the proliferation of videos on the internet has made it possible to exploit bugs in decoder software that allow the attacker to gain escalated privileges on the system against the user's interests by showing them a specially crafted video with hidden, malicious code.

EDIT2: Your 4-speed manual gearbox example can be made into a good exposition of "engineering tradeoffs". It could be that the engine has a power-band so broad that the gearbox can be made with stronger gears and less complexity (fewer bushings, bearings, synchromeshes and moving parts) while still meeting the specific gearbox dimension, weight and manufacturing cost and overall performance design targets. One example of this is the 7.0L V8 engine and 4 speed gearbox Ford used in its 1966 Le Mans winning GT40 Mk II. For reliability reasons the engine was restricted to 6200 RPM even though it could run up to 7400 RPM in NASCAR trim (rotational kinetic energy depends on angular velocity squared and thus affects the acceleration and thus wear that the crankshaft and piston assembly experiences during each revolution) and its torque characteristics were such that sufficient thrust was produced above 3000 RPM in all gears so that it could still keep up with its opposition and reach a RPM-limited top speed of 205 mph at 6200 RPM down the Mulsanne straight with its 1.0:1 ratio 4th and final gear. Never mind that it was so heavy that Ford had to come up with a quick-change disc brake design (the brake disc size was limited by the 15" rims in use) that is still seeing wide use (with few variations) today. (source)

[schmidtbag]

AIUI, it is because assembly obscures the ideas you are trying to communicate to your fellow developers in favour of explicit control of hardware minutiae.

This is literally the reason why compilers were developed: To avoid having to write machine code directly, because it is too time consuming and cognitively taxing (and thus error prone) when humans are developing large software systems. Let's not forget that humans are the primary source of bugs in software.

Then why is such critical code in this encoder written in assembly at all? The more complicated your function is, the more cognitively taxing and error-prone it will be. To my understanding, writing an encoder is already complex, so I can't imagine how much harder it'd be to do fine tuning and access instruction sets in an already cognitively taxing language. In other words, a difficult language is used to write what may the hardest part to write for this encoder, and the easiest part is written in a relatively easy language. So, if using Rust was for the sake of reducing human error or to make the code more human-readable, well, that ship had already sailed.
Again - that's not necessarily a problem, just an odd approach, hence me not being the only one to notice it. I think it's great the rav1e devs care to go so deep with optimizations, because nobody does that these days and it does matter.

Only in the specific cases where the trade-off of increased cognitive load is worth it in terms of raw performance does it make sense to write code directly in assembly. And even then, you typically hide the assembly behind a cognitive-load-lessening macro-invocation in the code so the preprocessor can substitute the assembly code into the higher-level source code at compile time.

I understand that, which is what lead to my other question: why use Rust, as opposed to anything else? Unlike a lot of people here, I don't have a problem with Rust, but of every high-level language, I'm not sure I understand why that was chosen. And no, I'm not implying there's a better choice either.

[bug77]

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?

Safety, in this context, is not about "incriminating data". It's about thread safety, i.e. the encoder won't crash/segfault under conditions you didn't think about.