> Font shaping performance increased by 5-15% compared to the C++ version.
Personally, I wouldn't link it directly to rust, but to rewriting. When you develop something, you usually can't account for all future changes that affect performance, design, LOC, robustness, and so on. But with rewrite, you take them all into account. So there is a big chance that rewrite will be superior in many areas. It will probably have the same effect as if they had rewritten it in C++ again.
I don't think the claim is that Rust is faster than C++ in general. Rather, they mention this to address the worry that there is always a performance penalty for safety. This example (and many others) show that Rust doesn't compromise on performance. You won't always get 5-15% improvements, but it'll always be competitive.
I think you have to link it to more than one thing. Being able to write complex code in a performant way without being worried you've introduced another security bug in one of the most infamous subsystems for security is definitely a plus as it allows you to go after performance you might not otherwise have been able to go after in the alloted time/resources. At the same time, no two rewrites are the same and being able to look back and see how the current design performs and where it may be improved is also great insight into how to do it differently.
What I think this note bucks is the concept choosing a secure language to re-implement something in means performance overhead compared to C/C++ code that has had years or decades of work putting into it. It doesn't necessarily argue A or safe B is inherently faster, just that a safe B doesn't imply you should expect it to be safe and slower, just safe.
But rewriting after the exploratory phase is over (or to be more precise: long after the exploratory phase is over) is still an achievement of Rust: not only because it's fashionable (it sure is), but because it gives reasonable confidence that you won't find yourself regretting having rolled back multiple decades of weeding out lurking memory bugs.
A C rewrite promising a moderate speedup wouldn't so much be skipped because it was not worth the effort, they are not done because the speedup isn't worth the risk of having to go through all that again.
There might be a small advantage brought in by Rust. The Rust memory model (R^W, no aliasing) does mean that some compiler optimizations are broadly applicable in Rust, but only apply in C/++ where the developer has taken the care to signal those constraints to the compiler.
In this case it isn't a "in every way better second system designed from the ground up to include a kitchen sink", it's just an API-compatible rewrite in a different language.
I've never heard that "full saying" and Wikipedia says that people who claim this offer no citations for it. One of them is a 9/11 Conspiracy Theorist, the other listed is from one of the crazier than average US religious sects.
Maybe. Certainly it's not the case that Rust is just blanket 5-15% faster than C++ for tasks, not even in the vague hand waving way that Python is typically say 10x slower than C++ or Rust would be.
However, there are some ways that I'd expect similarly capable programmers are likely to often produce faster Rust code than C++ and much fewer ways I'd expect the opposite, so it's not a surprise when this work results in a small unlooked-for performance improvement.
Not quite sure about the down votes here, but there's quite a bit of activity in social media at the moment about performance, saying exactly the same as the parent, tl;dr if you get the data structures right, especially with hindsight, then vNext is almost certainly faster.
Andrew Kelley (zig) did a whole talk on data oriented design a while back talking about the same thing. And Casey Muratori is also talking about it a lot right now, and with good reason.
Certainly. Having requirements set in stone helps rewriting any code base. They probably get more time for optimization with the language handling a lot of the security and correctness issues as well as future changes.
Personally, I wouldn't link it directly to rust, but to rewriting. When you develop something, you usually can't account for all future changes that affect performance, design, LOC, robustness, and so on. But with rewrite, you take them all into account. So there is a big chance that rewrite will be superior in many areas. It will probably have the same effect as if they had rewritten it in C++ again.