Rav1e 0.1 Marks This Rust-Written AV1 Encoder's First Official Release

[phoronix]

Phoronix: Rav1e 0.1 Marks This Rust-Written AV1 Encoder's First Official Release

Rav1e has been in development for more than one year now as the "safest and fastest AV1 encoder" thanks to being written in Rust while now their first official release is available...

http://www.phoronix.com/scan.php?page=news_item&px=rav1e-0.1-Released

[deimios]

Safest and Fastest are mutually exclusive as safety checks (array bounds checking, type conversion checks, pointer bounds check and so on) cost processing power. Even if these checks could be and would be done in hardware, the cost is still there.
So if this implementation is currently the fastest then we lack a similar C implementation that skips the safety checks and which should be faster.

I like the premise of Rust but let's not go overboard with the speed claims.

[skeevy420]

Safest and Fastest are mutually exclusive as safety checks (array bounds checking, type conversion checks, pointer bounds check and so on) cost processing power. Even if these checks could be and would be done in hardware, the cost is still there.
So if this implementation is currently the fastest then we lack a similar C implementation that skips the safety checks and which should be faster.

I like the premise of Rust but let's not go overboard with the speed claims.

Oddly, I both agree and disagree with that premise depending on the use case. With so many things being always connected to the internet, programming in a language that makes exploits harder due to all the safety checks is a good thing. That isn't a feature, however, that one necessarily needs in regards to an offline rendering farm (since we're talking about an encoder here).

Sort of like running with mitigations=off or on, each has a proper time and place and can be justified similar to safety checks and skipping them.

[xnor]

Safest and Fastest are mutually exclusive as safety checks (array bounds checking, type conversion checks, pointer bounds check and so on) cost processing power.

This blanket statement is simply false.
Depending on the language, more or less checks can be done upfront by the compiler so during runtime there is no extra cost because there is no need to re-check invariants that the compiler already guarantees.

[rene]

This blanket statement is simply false.
Depending on the language, more or less checks can be done upfront by the compiler so during runtime there is no extra cost because there is no need to re-check invariants that the compiler already guarantees.

Plus the checks are often mostly there in C and C++, just often manual typed wrong, off-by-one or more. A couple of bounds checks on the input data in the beginning of a hot processing loop does not slow down the actual SIMD algorithm one bit. If Rust is the bets new language for the job is another questions though: https://www.youtube.com/watch?v=pBDrazBVmIo

[xnor]

Plus the checks are often mostly there in C and C++

No, they are not. If you get a crash you're lucky. Otherwise you'll land in undefined behavior hell.
You _can_ use "safe" implementations to get some safety but they are opt-in. ("safe" here in scare quotes as it takes careful manual programming because of these languages being unsafe themselves)

In Rust, it's the other way around.

If Rust is the bets new language for the job is another questions though: <self promoting youtube link>

I have no idea what you're wasting your time on there. Is this seriously a 35 minute live-stream on you trying to update rust?

[rene]

No, they are not. If you get a crash you're lucky. Otherwise you'll land in undefined behavior hell.
You _can_ use "safe" implementations to get some safety but they are opt-in. ("safe" here in scare quotes as it takes careful manual programming because of these languages being unsafe themselves)

In Rust, it's the other way around.

Of course allure reasonable "production quality" C and C++ code has string, array, etc. bounds checks all over the place, or do you think the Linux kernel or Firefox/Chrome would be somewhat secure without these?

I have no idea what you're wasting your time on there. Is this seriously a 35 minute live-stream on you trying to update rust?

Who says trying? Updating, In your favorite Linux distribution someone has to do the work. Or do you think it updates magically. Plus implementing and testing some proper bootstrap procedure. It's not like exactly that is particular outstanding currently in Rust & Cargo land.

[bachchain]

Safest and Fastest are mutually exclusive as safety checks (array bounds checking, type conversion checks, pointer bounds check and so on) cost processing power. Even if these checks could be and would be done in hardware, the cost is still there.
So if this implementation is currently the fastest then we lack a similar C implementation that skips the safety checks and which should be faster.

I like the premise of Rust but let's not go overboard with the speed claims.

Pointer and type conversion are mostly done at compile time, while array bounds checking is only done in certain circumstances. Even then, you can explicitly opt out of all of them.

[emblemparade]

Even if these checks could be and would be done in hardware, the cost is still there.

Not if the cost is incurred during compilation. Rust's safety features are (for the most part) purely grammatical.

Anyway, a simple if-comparison is orders of magnitude faster than anything else going on in a normal program (call stack manipulation, memory allocations, etc.). If you remove such runtime safety checks it is highly doubtful that you would get any noticeable performance boost.

The "speed claims" for Rust (who is making them?) may have to do with it encouraging good programming practices: it's concise and expressive, and does that without (too much) code hiding. C++, by contrast, is notorious for having costly constructor/destructor/operator-override calls inserted for you.

[anarki2]

Safest and Fastest are mutually exclusive as safety checks (array bounds checking, type conversion checks, pointer bounds check and so on) cost processing power. Even if these checks could be and would be done in hardware, the cost is still there.
So if this implementation is currently the fastest then we lack a similar C implementation that skips the safety checks and which should be faster.

I like the premise of Rust but let's not go overboard with the speed claims.

Uh, stupidest comment of the day awarded. Maybe try some actual programming first, or better yet, profiling, then come back to the matter. In the future you might as well try talking about stuff you have at least a slight idea about.