Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Rust faster than C?

steveklabnik.com

Post reply on HN
Print view View original

291–300 of 402 posts

Re: Is Rust faster than C?

#291

Post by dwattttt »

jandrewrogers wrote: post #286
josephg wrote: post #270

Earlier quoted context omitted.

It is?? Can you give some examples of high performance stuff you can do using C++'s template system that you can't do in rust?

They are likely referring to the scope of fine-grained specialization and compile-time codegen that is possible in modern C++ via template metaprogramming. Some types of complex optimizations common in C++ are not really expressible in Rust because the generics and compile-time facilities are significantly more limited. As with C, there is nothing preventing anyone from writing all of that generated code by hand. It…

> As with C, there is nothing preventing anyone from writing all of that generated code by hand. It is just far more work and much less maintainable than e.g. using C++20.

It's also still less elegant, but compile time codegen for specialisation is part of the language (build system?) with build.rs & macros. serde makes strong use of this to generate its serialisation/deserialisation code.

Re: Is Rust faster than C?

#292

Post by jenadine »

sebtron wrote: post #126
groundzeros2015 wrote: post #120

Earlier quoted context omitted.

Yes it can used to reduce latency of a particular task. Did you read my points about when it’s not helpful? Are people making user facing apps in rust with GUIs?

> Are people making user facing apps in rust with uis? We are talking not only about Rust, but also about C and C++. There are lots of C++ UI applications. Rust poses itself as an alternative to C++, so it is definitely intended to be used for UI applications too - it was created to write a browser! At work I am using tools such as uv [1] and ruff [2], which are user-facing (although not GUI), and I definitely apprec…

> There are lots of C++ UI applications.

Is there? UI applications historically used to be written in C++. But in this decade, I don't think many new GUI are being written in C++

Re: Is Rust faster than C?

#293

Post by notorandit »

It is machine code in the end, right?

We all have optimizing compilers in 21st century, right?

So, "yes, compilers can have different speeds. No matter the language."

And "no, C and rust are both fast" unless compiler limitations kick in.

Re: Is Rust faster than C?

#294

Post by dwattttt »

oguz-ismail2 wrote: post #287
steveklabnik wrote: post #203

Earlier quoted context omitted.

Rust doesn't call into libc for sort, it has its own implementation in the standard library.

Obviously. How about more complex things like multi-threading APIs though? Can the Rust compiler determine that the subject program doesn't need TLS and produce a binary that doesn't set it up at all, for example?

Optimising out TLS isn't going to be a good example of compiler capability. Whether another thread exists is a global property of a process, and beyond that the system that process operates in.

The compiler isn't going to know for instance that an LD_PRELOAD variable won't be set that would create a thread.

Re: Is Rust faster than C?

#295

Post by mandw »

josephg wrote: post #284
mandw wrote: post #277

Earlier quoted context omitted.

The only real question I have with this is did the program have to have any specific performance metric? I could write a small utility in python that would be completely acceptable for use but at the same time be 15x slower than an implementation in another language. So you do you compare code across languages that were not written for performance given one may have some set of functions that happens to favour one la…

Honestly I'm not quite sure what point you're making. > If he needed his app to be 30% faster he would have made it so Would he have? Improving performance by 30% usually isn't so easy. Especially not in a codebase which (according to Cantrill) was pretty well optimized already. The performance boost came to him as a surprise. As I remember the story, he had already made the C code pretty fast and didn't realise his…

I did feel my post was a bit unneeded when I added my edit :)

   My point about the  30% was that you mentioned that he got in rust and attributed it to essentially, better algorithms in the rust lib he used.  Once he knew that then its hard to say that rust is 'faster' but the point is valid and I accept that he gained performance by using the rust library.

   My other point was that the speed of his code probably didn't matter at the time. If it was a problem in the past he probably would have taken the time to profile and gain some more speed.  Sure you cant gain speed that can't be had but as you pointed out, it wasn't a language issue, it was an implementation of the library issue.

   He could have arbitrarily used a different program that used a good library and the results reversed.

   I also agree that most devs are not working down at that level of optimisation so the default libraries can help but at the same time it mostly doesnt matter if something takes 30% longer if that overall time is not a problem.   If you are working on something where the speed really matters and you are trying to shave off milliseconds then you have to be that developer that can work C or Rust at that level.

Re: Is Rust faster than C?

#296

Post by dwattttt »

kevincox wrote: post #263
stevefan1999 wrote: post #262

Yes, in general Rust is faster than C, I would argue, because there are some problems the hinders C performance such as strict aliasing and volatile data simply doesn't exist in Rust, and immutable const propagation and const evaluation works too.

Yes, the same way is that Fortran is faster than C due to stricter aliasing rules. But in practice C, Rust and Fortran are not really distinguishable on their own in larger projects. In larger projects things like data structures and libraries are going to dominate over slightly different compiler optimizations. This is usually Rust's `std` vs `libc` type stuff or whatever foundational libraries you pull in. For most…

> In larger projects things like data structures and libraries are going to dominate over slightly different compiler optimizations.

At this level of abstraction you'll probably see on average an effect based on how easy it is to access/use better data structures and algorithms.

Both the ease of access to those (whether the language supports generics, how easy it is to use libraries/dependencies), and whether the population of algorithms and data structures available are up to date, or decades old, would have an impact.

Re: Is Rust faster than C?

#297

Post by dwattttt »

pron wrote: post #189
jillesvangurp wrote: post #58

Earlier quoted context omitted.

It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more co…

> It's compilers and compiler optimizations that make code run fast. Compiler optimisations certainly play a large role, but they're not the only thing. Tracing-moving garbage collectors can trade off CPU usage for memory footprint and allow you to shift costs between them, so depending on the relative cost of CPU and RAM, you could gain speed (throughput) in exchange for RAM at a favourable price. Arenas also offer…

It might be a minute or two before we get to see the words "favourable price" anywhere near the word RAM again.

Re: Is Rust faster than C?

#298

Post by shevy-java »

> An example of this from a long time ago is the Stylo project. Mozilla tried to parallelize Firefox’s style layout twice in C++, and both times the project failed. The multithreading was too tricky to get right. The third time, they used Rust, and managed to ship

I am getting tired of those Rust-promo comments citing Firefox or other projects from Mozilla that also fail.

Mozilla has consistently lost market share with Firefox. Nowadays it pushes things into it that the users do not want, so the death-cycle continues here; the whole AI slop is a wonderful example of this. I even had those things hover out (!) of firefox into other parts of my IceWM desktop. Even if this may be a separate bug or related to nouveau, why are those things I don't need, hovering outside of Firefox to begin with? I never asked or wanted for those things; Mozilla dictated that onto me.

Yet there are people such as Steve, who constantly promote Rust - and cite Firefox or Mozilla. Something does not work here; the promo should instead be "thanks to Rust, Firefox is now chasing Chrome realistically again". But this is not happening. So why the promo? You can not promote a new language by pointing at failing projects. That makes no sense.

Re: Is Rust faster than C?

#299

Post by pjmlp »

MeetingsBrowser wrote: post #230
pjmlp wrote: post #171

Earlier quoted context omitted.

And the C++ version is add std::execution::par_unseq as parameter to the ranges algorithm.

This has the same drawbacks as "#pragma omp for". The hard part isn't splitting loop iterations between threads, but doing so _safely_. Proving an arbitrary loop's iterations are split in a memory safe way is an NP hard problem in C and C++, but the default behavior in Rust.

Well, if you are accessing global data with ranges, you are doing it wrong.

Naturally nothing on C++ prevents someone to do that, which is why PVS, Sonar and co exist.

Just like some things aren't prevented by Rust rather clippy.

Re: Is Rust faster than C?

#300

Post by oguz-ismail2 »

dwattttt wrote: post #294
oguz-ismail2 wrote: post #287

Earlier quoted context omitted.

Obviously. How about more complex things like multi-threading APIs though? Can the Rust compiler determine that the subject program doesn't need TLS and produce a binary that doesn't set it up at all, for example?

Optimising out TLS isn't going to be a good example of compiler capability. Whether another thread exists is a global property of a process, and beyond that the system that process operates in. The compiler isn't going to know for instance that an LD_PRELOAD variable won't be set that would create a thread.

> Whether another thread exists is a global property of a process, and beyond that the system that process operates in.

TLS is a language feature. Whether another thread exists doesn't mean it has to use the same facilities as the main program.

> The compiler isn't going to know for instance that an LD_PRELOAD variable won't be set that would create a thread.

Say the program is not dynamically linked. Still no?

Post reply on HN