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

[bug77]

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.

This is probably about the zero-cost abstractions Rust is so proud about.

[jjkk]

The whole point of "safest" *encoder* is just laughable and idiotic. Totally in sync with other buzzwords for the sectarian user-base who learned programming two weeks ago. How on earth one would write unsafe encoder? The input data is a sequence of bitmaps. How would one even be able to grab and process those pixels unsafely?

I would arguably stand the "safest" for a decoder where the bit stream syntax and decoder state should indeed be checked carefully. Still not a rocket science at all.

But "safe" encoder is just another shiny word for a dumb slogan-eaters e.g. rust sectarians.

[bug77]

The whole point of "safest" *encoder* is just laughable and idiotic. Totally in sync with other buzzwords for the sectarian user-base who learned programming two weeks ago. How on earth one would write unsafe encoder? The input data is a sequence of bitmaps. How would one even be able to grab and process those pixels unsafely?

I would arguably stand the "safest" for a decoder where the bit stream syntax and decoder state should indeed be checked carefully. Still not a rocket science at all.

But "safe" encoder is just another shiny word for a dumb slogan-eaters e.g. rust sectarians.

You can craft a malicious stream to break just about anything. Not a huge problem per se, but then again, neither was speculative execution. Until it was.

But I believe "safe" in this context is about the safe code the compiler generates, as opposed to other code that needs more thorough auditing *cough*OpenSSL*cough*

[skeevy420]

How on earth one would write unsafe encoder?

Intentionally, like the same way some assholes add an rm -rf /etc/* in a sudo script or unintentionally, like it reads a 0 from the wrong part of memory so it writes its data starting at sector 0 of the drive and ruins your data.

Paraphrasing bug77, not a problem until it is so better safe than sorry.

[jjkk]

Intentionally, like the same way some assholes add an rm -rf /etc/* in a sudo script or unintentionally, like it reads a 0 from the wrong part of memory so it writes its data starting at sector 0 of the drive and ruins your data.

Paraphrasing bug77, not a problem until it is so better safe than sorry.

So they did not put any malicious code in it and are proud of that? Ok.

An analogy with car manufacturer comes to mind: our car has the roundest tires on the market and we did not put any explosive in them!

I would get it as a light joke if there was no word "rust" in the topic. Even that analogy is used as valid selling points today.

[skeevy420]

So they did not put any malicious code in it and are proud of that? Ok.

An analogy with car manufacturer comes to mind: our car has the roundest tires on the market and we did not put any explosive in them!

I would get it as a light joke if there was no word "rust" in the topic. Even that analogy is used as valid selling points today.

What did they do? Use base 60 mathematics to get a more accurate definition of Pi?

Another analogy with car manufacturers could be: our car has the nicest gas pedal on the market; oh crap, they get stuck in place and you get to experience how well they accelerate and hopefully have good enough brakes and rotors to pass your unexpected brake tests.

For phone manufacturers: our phone has the most powerful and longest lasting battery; whoops, seems they have a catching fire and/or exploding issue.

The malicious code was only half of it and is the unlikely scenario (at least in the open source world). It's those unintended, unintentional problems, like the gas petal getting stuck or your phone mysteriously going ablaze, that Rust is designed to help with thanks to all its compiler checks.

[profoundWHALE]

For those who are curious, I've gotten approx. 1.75x the encoding speed from this update.

[Alliancemd]

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.

You have misconceptions about what Rust does, I would recommend trying to read about Rust.
Safety is not through "bounds checking", but through some core rules that make sure you don't do the typical memory handling errors, all at compile-time.
There is no "safety overhead"...