'Rust is So Good You Can Get Paid $20K to Make It as Fast as C' (itsfoss.com) 153
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.
It's just a front end to LLVM (Score:2, Informative)
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:2)
Re: (Score:3)
Programming is not an art, it's engineering. Decades of C programming has shown that *no* programmer at all is immune to bugs that are way too easy to do naturally when you can cast a pointer to an int and do whatever the fuck you want with it. True, it allows for insane optimization, but then you're subject to buffer overflows and other issues that come naturally with this lax attitude.
This problem was solved decades ago by Java and the like. When your pointers are a first class citizen and not a glorified
Re:It's just a front end to LLVM (Score:5, Interesting)
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)
CoPilot seems to like either PowerShell or C# for some reason. Go figure.
Re: (Score:2, Redundant)
Rust doesn't invoke Assembly. That is the problem. There is no way to invoke it because that defeats the purpose of using Rust.
If you want speed, you ONLY write software in C. Not C++, C.
If you want stability, you write software in whatever language has a stable runtime on all platforms.
If you want compatibility, you only write software in C99 (due to correct floating point support)
You only get intrinsics with C/C++, and then only with specific compilers and only on 64-bit https://learn.microsoft.com/en-us/
Re:It's just a front end to LLVM (Score:5, Insightful)
The compiler is turning Rust into assembly. This is what I mean about people don't know how things work anymore.
Have LLVM produce assembly listings of the Rust compiled code and the C compiled code. Then compare them. The Rust front end is likely not triggering some optimizations that C triggers. If you are a compiler expert compare the intermediate code which would be even faster. Once you identify what is happening adjust the Rust front-end.
Re: (Score:2)
the way to solve this is to study how the generated assembly language differs
Like executing extra code to check for various memory safety rules?
Re: It's just a front end to LLVM (Score:2)
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.
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)
You can't fix rust with sealer, because rust never sleeps. It requires acid.
CLR [clrclean.com.au] is an acid-based rust remover
Re: (Score:2)
I was thinking more like naval jelly or Ospho, both of which are based on phosphoric acid. But a clean toilet is nice, too... for me to poop in. Isn't it ionic? Specifically, cationic?
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:Call bullshit (Score:4, Interesting)
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:Call bullshit (Score:4, Insightful)
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:5, Informative)
Re: (Score:2)
How does Rust handle situations that can't be detected at compile time? Say I have a networking program that receives arbitrarily sized data, and I have to allocate buffers which have sizes indicated in the packet header. I allocate the buffer according to the size in the packet, then start picking it apart. What will Rust do if/when I try to access data beyond the allocated buffer size?
Re: (Score:2)
Do you somehow not have a maximum buffer size?
Re: (Score:2)
It depends. Often it panics. Signed overflow is turned to wrap-around in production, so you get silent logic errors.
Re: (Score:2)
By your logic all compiled languages are equally fast. This is not the case.
Re: Call bullshit (Score:3)
Re: (Score:2, Interesting)
It's clear from your comment that you didn't read what I wrote. All the languages I cited are compiled. Well, Rust and Go are. C# is just an illustration of why Rust is awful since it shares in some of Rust's moronicisms.
Rust's scope-based ownership system is garbage collection, just at scope change time, not separately.
Rust's inherent bounds checking, null-pointer dereference checking, abstraction overhead, and the borrow system all introduce unnecessary enforced overhead, overhead that is permanent and
Re: (Score:3)
"Rust's inherent bounds checking, null-pointer dereference checking, abstraction overhead, and the borrow system all introduce unnecessary enforced overhead, overhead that is permanent and ongoing. "
No. Most of Rusts checks are done at compile time without introducing any run time check overhead. Especially true of the borrow checker and null pointer checking. There may be bounds checks at run time but they can often be optimised away. They don't even exist if one uses Rusts iterators instead of indexing in
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)
True, the question is whether this should not better be a level of verification on top of C.
Re: (Score:2)
Rust just has too much inherent friction to ever be as elegant or useful.
Most programmers today can't even recognize elegance, let alone produce it. Most programmers prefer whatever language they learned while young.
Re: (Score:2)
C treats you like an adult. Which selects for things like double-free exploits
Like https://securityonline.info/po... [securityonline.info] , which, if C had stopped the developer from adding the memory pointer to two different lists, and freeing it from both, the root exploit wouldn't have existed.
Unless of course, the developers who maintain netfilter aren't adults.
Personally, I use C over Rust, because it's easier.
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)
On top of that, the use of software evolves, and software that might not have been expected to be internet facing may one day end up on the internet, security issues and all. So it is good practice to ensure software is secure by default, even if it is being used on an air-gapped computer in the middle of some remote desert.
Re: (Score:2)
We've even had malware that made it through the air gap.
Stuxnet and GSMem come to mind.
Oh, and let's not forget this:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Even an air gap isn't necessarily a solution for a dedicated attacker.
Re: (Score:2)
Also, the first rule of optimization: Don't do it.
ffmpeg (Score:4, 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:3)
the cost of safety (Score:3)
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 to be picked.
Re: (Score:3)
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)
This assumes the missing initialization or bounds check is a bug, and not simply redundant.
Re: (Score:2)
This assumes the missing initialization or bounds check is a bug, and not simply redundant.
Sure, although things can easily be thought redundant until some clever person makes it a bug ...
Re: (Score:2)
Maybe, but this does not imply that not having redundant checks is an issue with the original code, which was your comment.
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:3)
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:What's with the non-sequitir submission title? (Score:4, Informative)
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.
Re: (Score:3)
As a long time user of many languages, since 1980 in fact, as a user of Rust for the last five years and a follower of Rust forums and other channels I have to say I don't see a "cult like" community among Rust folks anymore than enthusiasts of any other language or technology. I don't see any more "bizarre" people there than anywhere else in society.
What I do see is this stupid, unfounded, and insulting characterisation being thrown at Rust devs and users all the time. What do you do that?
As it was written (Score:2)
Everything eventually decays to Rust [9cache.com].
Both sorts suck (Score:2, Interesting)
Obsessive Rust evangelists? Very annoying.
Obsessive Rust haters? Equally annoying.
A plague on both their houses.
That is all.
Rust Is So Good (Score:2)
Rust is so good, it would have caught pretty much all of the ffmpeg CVE's at compile time. From buffer overflows, to double frees, to null pointer dereferences, and use-after-free vulnerabilities.
Just have a look through the hundreds of examples over on cve.org , they're mostly doing bad things with pointers or memory management.
Re: (Score:2, Informative)
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:Finally... (Score:4, Informative)
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:4, Informative)
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)
I see you must be a Minecraft player if you think Java is by any means fast.
There is a reason why nobody uses Java for games. It's so incredibly slow. Just compare Bedrock (C++) to Java Minecraft and there is a huge performance gulf.
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)
> Sure, kernel drivers come to mind
Video decoders didn't come to mind?
Re: (Score:2)
> Sure, kernel drivers come to mind
Video decoders didn't come to mind?
Not for assembly. For video I would tend to use SIMD intrinsics rather than SIMD assembly. Intrinsics often seem to run faster since compilers generally can schedule the SIMD with the non-SIMD. I tend to try both, intrinsics and assembly, but experiments tend to give the win to intrinsics.
And if you want to say SIMD intrinsics in C/C++ code is still assembly language, I wouldn't argue. I see it as something a little different, even compared to inline assembly. I think the intrinsics interfere with compil
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: Finally... (Score:2)
According to what test?
Re:Finally... (Score:4, Informative)
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:On what planet? (Score:4, Informative)
Re:On what planet? (Score:5, Interesting)
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: On what planet? (Score:2)
Hence "when optimization was a lot more primitive."
Re: (Score:2)
Re:On what planet? (Score:5, Interesting)
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)
Re: (Score:3)
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)
You miss the most important aspect: "non-addressable piece of memory"
Re: (Score:3)
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.
Re: Finally... (Score:2)
Get alg right, but don't ignore everything else (Score:3)
Re: (Score:2)
That's simply not true.
Languages absolutely ARE fast or slow. Java is slow. Between delayed decisioning and garbage collection, it's not fast. C is generally very fast. It has risks, but it's fast. But this is because it's pointing at data, rather than at object that reference-count and bounds-check data.
Python is generally slow, but... so often the libraries are not themselves written in Python.
Re: (Score:2)
Yeah, who cares about 40 years of optimizations!