7 ms·
"faster than C" almost always boils down to different designs, implementations, algorithms, etc. Perhaps it is faster than already-existing implementations, su
by johnisgood 2y ago
"faster than C" almost always boils down to different designs, implementations, algorithms, etc.
Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.
- oneshtein 2y ago... because by "C" we mean handwritten inline assembler. Typical realworld C code uses \0 terminated strings and strlen() with O(len^2) complexity.
- qweqwe14 2y agoThe fact that it's faster than the C implementation that surely had more time and effort put into it doesn't look good for C here.
- johnisgood 2y agoIt says absolutely nothing about the programming language though.
- acdha 2y agoDoesn’t it say something if Rust programmers routinely feel more comfortable making aggressive optimizations and have more time to do so? We maintain code for longer than the time taken to write the first version and not having to pay as much ongoing overhead cost is worth something.
- jason-johnson 2y agoHow can it not? Experts in C taking longer to make a slower and less safe implementation than experts in Rust? It's not conclusive but it most certainly says something about the language.
- johnisgood 2y ago> Experts in C taking longer to make a slower and less safe implementation than experts in Rust? How do you know this exactly?
- vkou 2y agoI think you'll find that if you re-write an application, feature-for-feature, without changing its language, the re-written version will be faster.
- renewiltord 2y agoThis is known as the Second System Effect: where Great Rewrites always succeed in making a more performant thing.
- cb321 2y agoI am not sure if the semantics have drifted over the decades to what you say, but this seems not quite right according to wikipedia: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect EDIT: but I do agree that starting greenfield from an old code base is often a path towards performance.
- renewiltord 2y agoJust having a laugh, mate, but it is nice to have the truth posted as well.
- jandrewrogers 2y agoC++ surpassed C performance decades ago. While C still has some lingering cachet from its history of being “fast”, most software engineers have not worked at a time when it was actually true. C has never been that amenable to scalable optimization, due mostly to very limited abstractions and compile-time codegen.
- xxs 2y agozlib-ng is pretty much assembly - with a bit of C. There is this quote: but was not entirely fair because our rust implementation could assume that certain SIMD capabilities would be available, while zlib-ng had to check for them at runtime zlib-ng can be compiled to whatever target arch is necessary, and the original post doesn't mention how it was compiled and what architecture and so on. It's another case not to trust micro benchmarks
- tdiff 2y agoNevertheless Russinovich actually says something in the lines of "simple rewriting in rust made some our code 5-15% faster (without deliberate optimizations)": https://www.youtube.com/watch?v=1VgptLwP588&t=351s https://www.youtube.com/watch?v=1VgptLwP588&t=351s
- pinkmuffinere 2y agoI’m sure I’m missing context, and presumably there are other benefits, but 5-15% improvement is such a small step to justify rewriting codebases. I also wonder how much of an improvement you’d get by just asking for a “simple rewrite” in the existing language. I suspect there are often performance improvements to be had with simple changes in the existing language
- tdiff 2y agoI agree that simple rewriting could have given some if not all perf benefits, but can it be the case that rust forces us to structure code in a way that is for some reason more performant in some cases? 5-15% is a big deal for a low-level foundational code, especially if you get it along with some other guarantees, which may be of greater importance.
- turtletontine 2y agoFar better justification for a rewrite like this is if it eases maintenance, or simplifies building/testing/distribution. Taking an experienced and committed team of C developers with a mature code base, and retraining them to rewrite their project in Rust for its own sake is pretty absurd. But if you have a team that’s more comfortable in Rust, then doing so could make a lot of sense - and, yes, make it easier to ensure the product is secure and memory-safe.
- johnisgood 2y ago> if you have a team that’s more comfortable in As is the case with any languages, of course, it is not in favor (nor against) Rust.
- 2y ago
- kgeist 2y agoI heard that aliasing in C prevents the compiler from optimizing aggressively. I can believe Rust's compiler can optimize more aggressively if there's no aliasing problem.
- layer8 2y agoC has the restrict type qualifier to express non-aliasing, hence it shouldn’t be a fundamental impediment.
- gf000 2y agoWhich is so underused that the whole compiler feature was buggy as hell, and was only recently fixed because compiling Rust where it is the norm exposed it.
- vacuity 2y agoMy understanding is that noalias isn't fully utilized by LLVM, just that it's less buggy now, so there's some uncertainty leaning in favor of Rust in terms of future Rust-specific optimizations. Certainly a language like Fortran, with its restrictions, delivers accordingly on optimization, so I imagine Rust has plenty of room to grow similarly.
- cozzyd 2y agoI believe it was mostly an llvm problem and gcc supports restrict fine thanks to Fortran support
- anon-3988 2y ago> fundamental impediment This is an interesting word. I wonder why no one has written high performance library code in assembly yet at this point?
- johnisgood 2y agoWell, most of them is written in C/C++ and Fortran, is it not the case?
- deleted 2y ago[deleted]
- layer8 2y agoIf anything, this should be “zlib-rs is faster than zlib-ng”, but not “$library is faster than $programming_language”.
- chjj 2y ago[flagged]
- pdimitar 2y agoI am hopping on Rust threads on HN very regularly and I have to tell you my anecdotal experience. Which is: people complaining about Rust zealots are much more than actual Rust zealots. Thinking of it, I haven't seen a proper Rust zealot on HN for at least a year at this point. So I don't know, maybe do less cheap digs. Tearing down straw men is pretty boring to watch.
- chjj 2y agoWe have very different experiences then. Don't know what to tell you. Every interaction I've had with a rust programmer has led me to believe they are a toxic community of cultists. It's unlike any programming community I've seen.
- scns 2y ago> Every interaction I've had with a rust programmer has led me to believe they are a toxic community of cultists. Since the brain rates negative experiences more highly, it may have you believe such a generalisation, no?
- eru 2y agoI use Rust reasonably often. It's a decent language. Mostly more bearable than eg C++ or Go. > It's unlike any programming community I've seen. Oh, you clearly haven't hung out with the Haskellers in their prime.
- simonask 2y ago
- pveierland 2y agoOne big part I've noticed when working in rust is that, because the compilation and analysis checks you're given are so much stronger than in C or C++, and because the ecosystem of crates is so easy to make use of, I'll generally be able to make use of more advanced algorithms and methods. I'm currently working with ~150 dependencies in my current project which I know would be a major hurdle in previous C or C++ projects.
- ForTheKidz 2y agoEverything you said is correct of course, but the idea of auditing 150 dependencies makes me feel ill. It's essentially impossible for a single person.
- steveklabnik 2y agoThis is why sharing code is so important; it doesn't fall on one person, but instead, on the overall community. For example, cargo-vet and cargo-crev allow you to rely on others you trust to help audit dependencies.
- pveierland 2y agoOh, absolutely. Software cannot scale without trust. No single person is capable of auditing their browser or operating system either.
- maccard 2y agoThe effort is _roughly_ proportional - if you need to parse JSON in either language you can write it yourself or use an existing library. Both of those are the same amount of work in c++ and rust.
- atoav 2y agoThe thing is, Rust allows you to casually code things that are fast. A few years back I took part in an "all programming languages allowed" competition on a popular hacker blog in my country. The topic was who writes the fastest tokenizer (a thing splitting sentences into words). I took 15 minutes to write one in Rust (a language I had just learned by that point) using a "that should work" approach and became second place, with some high effort C-implementations being slower and a highly optimized assembler variant taking first place. Since then I programmed a lot more in C and C++ as well (for other reasons) and got more experience. Rust is not automatically faster, but the defaults and std library of Rust is so well put together that a common-sense approach will outperform most C code without even trying – and it does so while having typesafety and memory safety. This is not nothing in my book and still extremely impressive. The best thing about learning Rust however was how much I learned for all the other languages. Because what you learn there is not just how to use Rust, but how to program well. Understanding the way the Rust borrow checker works 1000% helped me avoiding nasty bugs in C/C++ by realizing that I violatr ownership rules (e.g. by having multiple writers)
- johnisgood 2y agoWell, yeah, same with books on Erlang, Common Lisp, even Odin. They teach you how to become a "better" (debatable, perhaps) programmer.
- jason-johnson 2y agoThis has generally been the case, but a system language like Rust has access to optimisations that C simply won't have due to the compiler having so much more information (e.g. being able to skip run time array size checks because the compiler was able to prove out of bounds access cannot occur).