'Rust is So Good You Can Get Paid $20K to Make It as Fast as C' (itsfoss.com) 70
The Prossimo project (funded by the nonprofit Internet Security Research Group) seeks to "move the Internet's security-sensitive software infrastructure to memory safe code." Two years ago the Prossimo project made an announcement: they'd begun work on rav1d, a safer high performance AV1 decoder written in Rust, according to a new update:
We partnered with Immunant to do the engineering work. By September of 2024 rav1d was basically complete and we learned a lot during the process. Today rav1d works well — it passes all the same tests as the dav1d decoder it is based on, which is written in C. It's possible to build and run Chromium with it.
There's just one problem — it's not quite as fast as the C version...
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, and, frankly, it just bothers us. The development team worked hard to get it to performance parity. We brought in a couple of other contractors who have experience with optimizing things like this. We wrote about the optimization work we did. However, we were still unable to get to performance parity and, to be frank again, we aren't really sure what to do next.
After racking our brains for options, we decided to offer a bounty pool of $20,000 for getting rav1d to performance parity with dav1d. Hopefully folks out there can help get rav1d performance advanced to where it needs to be, and ideally we and the Rust community will also learn something about how Rust performance stacks up against C.
This drew a snarky response from FFmpeg, the framework that powers audio and video processing for everyone from VLC to Twitch. "Rust is so good you can get paid $20k to make it as fast as C," they posted to their 68,300 followers on X.com.
Thanks to the It's FOSS blog for spotting the announcement.
There's just one problem — it's not quite as fast as the C version...
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, and, frankly, it just bothers us. The development team worked hard to get it to performance parity. We brought in a couple of other contractors who have experience with optimizing things like this. We wrote about the optimization work we did. However, we were still unable to get to performance parity and, to be frank again, we aren't really sure what to do next.
After racking our brains for options, we decided to offer a bounty pool of $20,000 for getting rav1d to performance parity with dav1d. Hopefully folks out there can help get rav1d performance advanced to where it needs to be, and ideally we and the Rust community will also learn something about how Rust performance stacks up against C.
This drew a snarky response from FFmpeg, the framework that powers audio and video processing for everyone from VLC to Twitch. "Rust is so good you can get paid $20k to make it as fast as C," they posted to their 68,300 followers on X.com.
Thanks to the It's FOSS blog for spotting the announcement.
When you're used to bloat taking 10s of seconds (Score:1)
to load a plain text website over a gigabit line, I suppose it's not too bad to get 95% of the speed of bare metal with a "safe" language.
It's just a front end to LLVM (Score:1)
Why would zero-cost-abstraction (ZCA) be any slower using the same compiler architecture?
Either yours or the existing C implementation, has bugs.
Yeah, it'll be the decades old C part (Score:2)
...that runs faster, not the almost new Rust one, thats got the bugs.
Yeah, that'll be it.
Re: (Score:2)
What "Decades old C" implementation of AV1 decoding?
AV1 was released in March 2018.
Re: (Score:3)
If there are any people left who know assembly language, the way to solve this is to study how the generated assembly language differs. Rust is telling the back end to do something differently. Track this down and you have your answer.
Re:It's just a front end to LLVM (Score:5, Funny)
Why don't they just ask ChatGPT to fix it? AI can do programming jobs, right?
Re: (Score:2)
AI/LLMs are far too fond on delivering you Python code. When not asked to. Even when clearly specifying that you don't want Python.
Re: (Score:2)
Re:It's just a front end to LLVM (Score:4, Informative)
Why would zero-cost-abstraction (ZCA) be any slower using the same compiler architecture?
The backend optimizer can only work with what it gets from the front end. In practice a mature front end will use lots of knowledge about the language to construct a good intermediate representation for the back end to make use of. My guess is that the Rust front end is not as mature as the C one.
Finally... (Score:1)
Re: (Score:3)
And there you are wrong. The thing is languages limit the maximum speed you can get and languages can make it easy or hard to reach that speed. And yes, languages can to _worse_ than giving you bad constant factors. I thing you have no clue what you are talking about. Not the first time.
Re: (Score:3)
Except in this case there's literally a 5% performance hit for the same code, even after specific professional optimisation for the Rust implementation.
So, yes... the language is "slower" than the equivalent C code. Same way that Java was always slower because by its nature it's interpreted, virtualised or using just-in-time compilation rather than running as native machine code.
Re: Finally... (Score:2)
Java isn't really interpreted. It's typically JIT compiled to native code. It's very fast once fully compiled (and assuming things like a good GC).
Re: (Score:2)
You think JIT-ed Java is "very fast"? Compared to what, interpreted Java? Seriously, all you do is show that you have no clue.
I LOVE programming in assembly language ... (Score:2)
Except in this case there's literally a 5% performance hit for the same code, ....
I LOVE programming in assembly language. But if I can only beat the compiler by 5% the project implementation is going to remain in its original high level language. The assembly not work future maintenance complications. The assembly implementation a fun experiment I did which now just sits in a branch of the source code.
Similar story for an implementation in a different high level language. A fun experiment, it's in a branch so it's not lost. Most likely not worth the future maintenance complications.
Re: (Score:2)
The language itself might not be fast or slow, but the implementation of it (e.g. the implementation of strcpy() for C) can be fast or slow, depending on the implementation. There is also compiler optimization and things like that which could be interpreted as being part of the language as that is how people usually see them.
For example if you are old enough, you might remember how Java was framed as a slow language. But after JIT compilation was introduced, Java became much faster, which improved even more
Re: (Score:2)
and is still very slow compared to C.....
Re: (Score:2)
Languages for sure can be slow. For example, they can cause larger memory-footprints and lugging that around causes less effective caches. There is no way to fix this type of characteristic via a compiler.
On what planet? (Score:2)
Write the exact same algorithm in C and in Python and time them. The C could run up to 100x faster depending on what also it is.
The language *syntax* and paradigm might not make a difference to speed, but language implementations (interpreters, compilers, libraries) most certainly do.
Re: (Score:3)
Re: (Score:3)
Very much so. When optimization was a lot more primitive, a=a+1 was slower than ++a because the latter resulted in INC and the former loaded a register with 1 and used ADD.
Re: (Score:2)
Re: (Score:2)
Watch the Youtube channel: Dave's Garage. There is a video series where he has a simple code proposition and keeps measurements of code implementations to complete this proposition. Everyone can enter, using their favorite language. You say "C is 100x faster". His scoreboard indicates more like 10000x faster. See here [youtube.com].
Re: (Score:2)
The thing that speeds up C the most here is that C runs with a far smaller memory work set. That can boost cache effectiveness dramatically.
Re: (Score:2)
The language *syntax* and paradigm might not make a difference to speed
That is absolutely not true. The way languages are specified might enable or prevent particular optimization.
The classic example is the introduction of "restrict" in C which enabled some optimization which would not have been semantically correct otherwise.
In python has a million language specification issues which prevent a bunch of optimization. In python for instance, it might not be possible to tell through static analysis whether an allocated object will remain in the scope of the function that declare
Re: Finally... (Score:2)
"Languages aren't "fast" or "slow""
Yes they are. What are you smoking? There are effective ways to use any language, but to claim they don't have different performance characteristics is ridiculous.
Python is slow. It's also used extensively in machine learning, one of the most compute intensive tasks there is. So, all the ML stuff is written in C and imported in libraries. If you don't realize that the language itself is very slow, you will not be able to develop performant software using it.
Some languages
Re: (Score:2)
"Python is slow. It's also used extensively in machine learning, one of the most compute intensive tasks there is."
But Python isn't used for the compute intensive parts.
"If you don't realize that the language itself is very slow, you will not be able to develop performant software using it."
You are not able to develop performant software using Python, you may be able to develop performant software where non-performant portions use Python.
"Java is fast, but is slow to startup."
Java is garbage collected. Garb
Re: (Score:3)
Python isn't slow. The CPython interpreter is slow. There are multiple Python compliers/translators/whatevers that can take Python code and turn it into machine code that's just as fast as C in many circumstances, with "many circumstances" getting more and more complete as time goes on.
The OP is correct, if a bit pedantic. Languages aren't slow or fast, compilers/interpreters are. Languages can certainly make it easier or harder to write a fast compiler/interpreter though.
Re: (Score:2)
Indeed. While Python is indeed slow, Python libraries are typically written in C and are not neccessarily slow.
Pythin is in a sense a "nanny language": You get to call the heavy lifing, but you cannot write it yourself (in Python).
Re: (Score:2)
Languages aren't "fast" or "slow"
I am, at best, a kiddie scripter who doesn't even know what a register is. And I know this statement is silly.
Re: (Score:2)
A register is a small, high performance piece of static memory closely connected to the functional units of a processor core which contains a source operand or memory address for an instruction, or receives a result, into which or from which an operand, address, address fragment or result is copied to/from an address in memory or another register. (Or if it's a flag register, it contains a series of bits with information about processor state, and/or the last operation executed.)
And you're right, it was a s
Re: (Score:2)
A register is a small, high performance piece of static memory closely connected to the functional units of a processor...
Is this because there's an unfortunate latency involved with a proc asking a RAM or ROM chip for a number in memory? So instead of using (metaphorically speaking) 1 cycle to answer an equation it might take 100 because a value needs to be pulled first?
Re: (Score:2)
Yes. That extra latency is mostly due to address decoding -- it takes more time to look up the right subset of the memory array when there are more items to select between -- and partly due to distance, both in terms of how many multiplexers (between different data paths) are in the way and physical distance.
Physical distance isn't normally a huge contributor: the signal travels at close to the speed of light, which is about 9 cm per cycle at 3 GHz. A typical processor core is so small that travel time is
Re: (Score:2)
Is this because there's an unfortunate latency involved with a proc asking a RAM or ROM chip for a number in memory?
That's right. The more work you can do without having to load from or store to memory, the better. We have both instruction and data caches on the processor for the same reason, that RAM is still faster than going to system RAM.
Re: (Score:2)
Re: (Score:2)
You must be one of the Rust delulus. No, compiling to machine code does _not_ give you an automatic advantage in performance over "high-level" languages. And no, garbage-collected languages do not need to be slow. That entirely depends in both cases.
But keep pushing lies. Eveybosy alreasy knows the Rust-fanatics have a loose screw. Keep this up and you will destroy what residual respect you still have.
Get alg right, but don't ignore everything else (Score:2)
To quote my friend Karl (Score:2)
"It's easier to make a working program fast, than to make a fast program work."
(and "work" should always include "secure".)
Re: (Score:3)
Re: (Score:2)
How much computation is he willing to spend to be sure his route is definitely as short as possible, rather than just "almost certainly pretty close" with a probabilistic, approximate algorithm?
And how many stops does he need to support? 10 stops is only 3.6 million possible routes, which is easy to do exhaustively. 16 stops grows to 20 billion possible routes, but that wouldn't take very long either if you farm it out on a 1000-"thread" GPU.
Call bullshit (Score:5, Interesting)
That's the Rust justification talking.
Rust is to C as Duplo is to Lego. You can build anything with Rust, provably because it's Turing complete. Just as Duplo has interlocking blocks that, with enough of them and enough patience can be used to build anything. But it will either be twice as big or half as fast. Rust just has too much inherent friction to ever be as elegant or useful.
Rust is an appropriate name for the language. Anything it touches needs "C"lr to fix.
C doesn't tell you where you can go or what you can do. C doesn't look at your code and tell you "Sorry, I can't do that Dave". C will always, ALWAYS just open the fucking pod bay doors when you tell it to.
Rust selects for poor programming skills. It selects for programmers who don't understand nuts and bolts and bit bashing and who don't understand why, yes, you still need to understand what a CPU is actually doing under the hood to make good, efficient programs. Hide all that, make bits and bytes dirty words, and you get programmers who don't know or care why their code is inefficient. Rust is a language that treats everyone like children you can't trust. You what happens when you do that? People act the way they are treated. C treats you like an adult, which selects for people who can handle that kind of responsibility.
Language like Rust (or Go or C# or worse) and that trend are why we need multiple gigahertz computers with tens of gigabytes of RAM to run a word processor.
Re: (Score:2)
Rust is an appropriate name for the language. Anything it touches needs "C"lr to fix.
You can't fix rust with sealer, because rust never sleeps. It requires acid.
C treats you like an adult, which selects for people who can handle that kind of responsibility.
I wish that were true, the second part I mean. There's just a lot of bad code out there instead, and then we get all these vulns with dumb causes that we've known about for decades.
Re: (Score:2)
I'll add that you probably learn more about programming and systems from a C program that goes wrong than a Rust program that can't go wrong (at least not in the same ways) and the former can help you become a better programmer, while the latter doesn't really teach you anything. On the other hand, missing an odd and/or occasional error situation in C can be disastrous. Review, testing and experience can help, but those are, unfortunately, not always the highest priorities.
Re: (Score:2)
I'll add that you probably learn more about programming and systems from a C program that goes wrong than a Rust program that can't go wrong (at least not in the same ways) and the former can help you become a better programmer, while the latter doesn't really teach you anything.
On the contrary, just getting a Rust program to successfully compile can teach you a whole lot about all the stuff you should have been worrying about with C or C++, but you were simply ignorant of or implicitly assumed would be OK.
Re: (Score:3)
And this is the reason pretty much all software around has so many security issues - developers too full of themselves write crap in C.
Re: (Score:2)
That _must_ be the reason for all those PHP vulnerabilities and all that insecure Java and JavaScript code! I am enlightened now!
Re: (Score:2)
Gatekeep much? Jesus Christ. Most people have to learn to crawl before learning to walk, let alone run. Just because you could build a Lego Technics superkit straight out of the womb doesn't mean everyone else should be able to.
I'd advise against break your arm patting yourself on the back too hard. Writing code with only one hand is at least 5% slower.
Re:Call bullshit (Score:4, Informative)
Re: (Score:2)
Rust selects for poor programming skills. It selects for programmers who don't understand nuts and bolts and bit bashing and who don't understand why, yes, you still need to understand what a CPU is actually doing under the hood to make good, efficient programs.
Indeed. Also, Rust is far too complicated with a number of paradigms thrown in and OO being half-ass. That whole thing screams "I am different for the sake of being differen!". Yes, I could work in it and use all of its features. But I am hardly an average coder.
Re: (Score:2)
C will always, ALWAYS just open the fucking pod bay doors when you tell it to.
Good analogy. Always doing something means invariably someone will ask and the entire ship will be emptied into the vacuum of space. If we had perfect humans then C would be great. We don't. Sometimes when someone says "Open the pod bay doors" the answer should be "No, they are interlocked for the safety of everyone".
Re: (Score:2)
"(and "work" should always include "secure".)"
Should it? Should security be enforced internally or externally? What if the program has no external connectivity?
Re: (Score:2)
"(and "work" should always include "secure".)"
Should it? Should security be enforced internally or externally?
Yes, and (unsurprisingly) it depends on what the program does.
What if the program has no external connectivity?
If the system has no external connectivity (or it secures the program against unauthorized access), all inputs are generated by the data owners, all users have equivalent access to all the data the program can access, there are no concerns about side channel information leaks, and incorrect or incomplete behavior are not considered "security" concerns (under the rubrics of integrity and availability, respectively), then the program can probably d
Re: (Score:2)
If the system has no external connectivity (or it secures the program against unauthorized access), all inputs are generated by the data owners, all users have equivalent access to all the data the program can access, there are no concerns about side channel information leaks, and incorrect or incomplete behavior are not considered "security" concerns (under the rubrics of integrity and availability, respectively), then the program can probably disregard security. The second and third items are uncommon in organizational environments.
While interesting, that seems more theoretical than reasonable.
I can't think of a situation where I'd trust those caveats to be a guarantee.
And, in places where that is a guarantee, they're going to still want security to be built into the application. At least I'd hope so.
But, yeah... I don't think I'd ever trust such a system to that degree. There are humans involved. Someone will get frustrated with that system and it won't be long before you'll find someone has figured out a way to sneak in their cell p
Re: (Score:2)
Also, the first rule of optimization: Don't do it.
ffmpeg (Score:2, Interesting)
They are the ones to talk. I mean, if any group must shut the fuck up in the Rust vs. C debate it's ffmpeg. They are one of the top reasons Rust had to be invented. Have they no shame? Reference: https://www.cve.org/CVERecord/... [cve.org]
Rest: Desperately Looking for Relevance (Score:2)
the cost of safety (Score:2)
The original code architecture was optimized for C. They used "the c2rust tool" to convert it initially, and then worked from there to optimize. Maybe the original overall design wasn't conducive to Rust.
Also, according to the article, the original C code did no bounds checking and no initialization of buffers. Doing that takes time.
"our profiling now indicates that the remaining overhead is spread roughly evenly across the largest, most complex functions in rav1d", sounds like no low-hanging fruit remains
Re: (Score:2)
Also, according to the article, the original C code did no bounds checking and no initialization of buffers. Doing that takes time.
Which they should have fixed/added to the original code, for no other reason than to make it better -- and then do the runtime comparison w/the Rust version.
Re: (Score:2)
From TFA that doesn't sound like the problem.
The initial pass generates non idiomatic rust which is mostly unsafe pointer dereferences, so it's semantically very close to C. Even that was a bit less efficient. My suspicion is that the Rust compiler front end is somewhat less mature than the C one.
It doesn't feel like there is an inherent reason for it to be slower: the code is instructing the compiler to do basically the same stuff in the same way and with the same optimizer. I reckon it's not doing as good
Re: (Score:2)
Also, according to the article, the original C code did no bounds checking and no initialization of buffers. Doing that takes time.
Which pretty much means they started with crap C code...
Could someone simply the rules for me? (Score:2)
Re: (Score:2)
What's with the non-sequitir submission title? (Score:2)
What has "rust is so good" got to do with the rest of the sentence?
Look, I like the idea of rust... but these bizarre masturbatory declarations sometimes seem ubiquitous in rust-land, and I believe they are the main thing that puts people off it.
Re: (Score:3)
They forgot the <sarcasm></sarcasm> tags.
Re: (Score:2)
...but these bizarre masturbatory declarations sometimes seem ubiquitous in rust-land, and I believe they are the main thing that puts people off it.
Indeed. The bizarre, cult-like community alone is a good reason to stay away.
As it was written (Score:2)
Everything eventually decays to Rust [9cache.com].