I have read papers for my bachelor’s thesis that compared rust and c on x86-64 in terms of performance. It showed that C is a little or significantly faster, depending on the type of workload.
This is likely due to some runtime checks the rust compiler adds, and modified rust compilers that added less runtime checks led to about the same performance.
However, the performance is still very good for both languages (native machine code being executed), and in the same order of magnitude.
My own measurements for the armv6m architecture with an STM-32 showed that rust may even be faster in some cases, since the optimizing of the rust compiler was better, at least for that setup and for the CRC-32 algorithm.
Unless you’re talking about some sort of reference counting, which has to be explicitly added by the programmer in cases where doing so is required for memory safety, I’m not sure what runtime checks you’re referring to?
From what I’ve seen, the performance of programs written in C and Rust are generally the same, more or less, with C or Rust coming out on top with roughly coinflip odds in a handful of cases. This feels like the primary differentiator in performance really comes down to the implementation of the person writing it, and less to do with any performance differences inherent to either language.
It’s open access, short, and really well written. Was a primary source of my bachelor’s thesis.
Figure 2 for the lazy people:
The results of this study suggest that rust programs can be a bit slower, or nearly match the performance of C programs on x86-64, and that the runtime checks play a big role in this dynamic.
Well, you need to type more and you need to learn more things with Rust, before you can start making stuff.
But the additional work is to make it easier for you to make changes later, when you come back to it after a while.
So you might need to do more before hello world, but say if you have a complex library and want to use some function of it after learning Rust, it will be easier to not make some common mistakes.
A pretty good recent example of something that will cause a common mistake would be:
In the mongoc library, there is a function named mongoc_client_select_server and the pointer it returns requires destruction using mongoc_server_description_destroy.
But it doesn’t say so in the function’s comments/documentation. So, I had to go into the function called by the function called by the function called by it, to find the function making said pointer and having a comment stating that the pointer made by it would require destruction by the user.
And the only reason I found that out was my obsession, but I had already made the mistake.
I’ve heard that while Rust has the ability to be faster than Go and maybe C, it is a lot harder to write rust code to do it
This is not true. If you know Rust and C equally well, you’re likely going to write equally performant Rust.
You could say that Rust is harder to learn than C. I’d disagree based on my personal experience, but you wouldn’t be wrong.
I have read papers for my bachelor’s thesis that compared rust and c on x86-64 in terms of performance. It showed that C is a little or significantly faster, depending on the type of workload.
This is likely due to some runtime checks the rust compiler adds, and modified rust compilers that added less runtime checks led to about the same performance.
However, the performance is still very good for both languages (native machine code being executed), and in the same order of magnitude.
My own measurements for the armv6m architecture with an STM-32 showed that rust may even be faster in some cases, since the optimizing of the rust compiler was better, at least for that setup and for the CRC-32 algorithm.
Unless you’re talking about some sort of reference counting, which has to be explicitly added by the programmer in cases where doing so is required for memory safety, I’m not sure what runtime checks you’re referring to?
From what I’ve seen, the performance of programs written in C and Rust are generally the same, more or less, with C or Rust coming out on top with roughly coinflip odds in a handful of cases. This feels like the primary differentiator in performance really comes down to the implementation of the person writing it, and less to do with any performance differences inherent to either language.
I found the study: https://doi.org/10.1145/3551349.3559494
It’s open access, short, and really well written. Was a primary source of my bachelor’s thesis.
Figure 2 for the lazy people:
The results of this study suggest that rust programs can be a bit slower, or nearly match the performance of C programs on x86-64, and that the runtime checks play a big role in this dynamic.
It’s things like out of bounds checking. I’ll go look for the paper and make another reply.
Well, you need to type more and you need to learn more things with Rust, before you can start making stuff.
But the additional work is to make it easier for you to make changes later, when you come back to it after a while.
So you might need to do more before hello world, but say if you have a complex library and want to use some function of it after learning Rust, it will be easier to not make some common mistakes.
A pretty good recent example of something that will cause a common mistake would be:
In the mongoc library, there is a function named
mongoc_client_select_serverand the pointer it returns requires destruction usingmongoc_server_description_destroy. But it doesn’t say so in the function’s comments/documentation. So, I had to go into the function called by the function called by the function called by it, to find the function making said pointer and having a comment stating that the pointer made by it would require destruction by the user.And the only reason I found that out was my obsession, but I had already made the mistake.