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

Performance of Rust Language [pdf]

github.com

Post reply on HN
Print view View original

141–146 of 146 posts

Re: Performance of Rust Language [pdf]

#141

Post by [deleted] »

Asraelite wrote: post #129
musicale wrote: post #107

Earlier quoted context omitted.

Is it outrageous because "performant" is kind of a vague term. Does it mean... Fast? GPU-friendly? Scalable? Energy-efficient? Reliable? User-friendly? Maintainable? For what kind of applications? Modern Fortran has a lot to offer for scientific and numeric computation - easier to learn than C++, and easier to optimize in many cases. Scales from small systems to supercomputers, and there is even CUDA Fortran.

> GPU-friendly? Scalable? Energy-efficient? Reliable? User-friendly? Maintainable? Nobody uses "performant" to refer to any of those. It usually means either high throughput, or some aggregate of high throughput + low latency + low memory usage.

[deleted]

Re: Performance of Rust Language [pdf]

#142

Post by musicale »

Asraelite wrote: post #129
musicale wrote: post #107

Earlier quoted context omitted.

Is it outrageous because "performant" is kind of a vague term. Does it mean... Fast? GPU-friendly? Scalable? Energy-efficient? Reliable? User-friendly? Maintainable? For what kind of applications? Modern Fortran has a lot to offer for scientific and numeric computation - easier to learn than C++, and easier to optimize in many cases. Scales from small systems to supercomputers, and there is even CUDA Fortran.

> GPU-friendly? Scalable? Energy-efficient? Reliable? User-friendly? Maintainable? Nobody uses "performant" to refer to any of those. It usually means either high throughput, or some aggregate of high throughput + low latency + low memory usage.

Thanks for the response - from my perspective the most meaningful measurement of "performance" (basically "efficiency" but also throughput) is computation per unit of energy (and heat which has to be dissipated), but memory efficiency is also important, as is tail latency in certain cases.

What does "Rust is roughly as performant as C" mean, do you think?

Re: Performance of Rust Language [pdf]

#143

Post by jccx70 »

jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

[dead]

Re: Performance of Rust Language [pdf]

#144

Post by jccx70 »

suis_siva wrote: post #27

I worked professionally with C, C++, Zig and Rust (in that order). My experience is that writing performant code is by far the easiest in C++, and by far the most difficult in C. Most of this, in practical experience, is due to ergonomics, in my opinion. Templates in C++ benefit from being part of the core language, -- stick a `template` above your `class`, and you're in metaprogramming land. Stick a template special…

[dead]

Re: Performance of Rust Language [pdf]

#145

Post by mswphd »

yogthos wrote: post #140
mswphd wrote: post #136

Earlier quoted context omitted.

for context: in rust the "translation unit" is a crate (in C++, each source file is its own translation unit). So you only get parallelism across crates when compiling in rust. When you have a single-crate project, this means that 1. you get parallelism across all your dependencies, but 2. your (final) crate is serial. Splitting your crate can therefore get you parallelism back in step 2, which can be a (compilation)…

Thanks, that's helpful to keep in mind. Looks like you can fiddle with organizing the project in way where you can balance 1 and 2 in a reasonable way. Right now, it's definitely the second step that's killing me where assembling the crates together takes forever.

you can try doing `cargo build --timings ...`. It will generate a report of how long each crate takes to compile etc. It sounds like you know that your final crate is the culprit, but this would let you confirm it.

If you suspect the issue is assembling all the files together (e.g. linking) you can see some advice on optimizing link speeds here

https://nnethercote.github.io/perf-book/build-configuration....

Note that there could be other causes of slow compilation of the final binary. For example, if you heavily use (especially procedural) macros, it's known to make compilation quite slow.

Re: Performance of Rust Language [pdf]

#146

Post by fithisux »

afdbcreid wrote: post #16
fithisux wrote: post #13

Earlier quoted context omitted.

You can write C style C++ and enjoy the same benefits. In Twitter a user explained me that it is common in embedded space. You do not need the OOP, RTTI, exceptions. Like C with most use cases of preprocessor replaced by generic programming.

So? How is that an argument that C++ is more performant than C? It's only an argument that it's not less performant.

It is an argument that you can make a faster C-like if you like out of C++
Post reply on HN