5 ms·

The real barrier is the C++ ecosystem. It represents the cost of losing decades of optimized, highly integrated, high-performance libraries. C++ maps almost per

The real barrier is the C++ ecosystem. It represents the cost of losing decades of optimized, highly integrated, high-performance libraries. C++ maps almost perfectly to the hardware with minimal overhead, and it remains at the forefront of the AI revolution. It is the true engine behind Python scientific libs and even Julia (ex. EnzymeAD). Rust does not offer advantages that would meaningfully improve how we approach HPC. Once you layer the necessary unsafe operations, C++ code in practice becomes mostly functional and immutable, and lifetimes matter less beyond a certain threshold when building complex HPC simulations. Or even outsourced to a scripting layer with Python.

amluto 10mo ago
> C++ maps almost perfectly to the hardware with minimal overhead Barely. The C++ aliasing rules map quite poorly into hardware. C++ barely helps at all with writing correct multithreaded code, and almost all non-tiny machines have multiple CPUs. C++ cannot cleanly express the kinds of floating point semantics that are associative, and SIMD optimization care about this. C++ exceptions have huge overhead when actually thrown.
- wrathofmonads 10mo ago
  In simulations or in game dev, the practice is to use an SoA data layout to avoid aliasing entirely. Job systems or actors are used for handling multithreading. In machine learning, most parallelism is achieved through GPU offloading or CPU intrinsics. I agree in principle with everything you’re saying, but that doesn’t mean the ecosystem isn’t creative when it comes to working around these hiccups.
- jcalvinowens 10mo ago
  > The C++ aliasing rules map quite poorly into hardware. But how much does aliasing matter on modern hardware? I know you're aware of Linus' position on this, I personally find it very compelling :) As a silly little test a few months ago, I built whole Linux systems with -fno-strict-aliasing in CFLAGS, everything I've tried on it is within 1% of the original performance.
  - amluto 10mo ago
    Even with strict aliasing, C and C++ often have to assume aliasing when none exists.
    - jcalvinowens 10mo ago
      If they somehow magically didn't, how much could be gained? I've never seen an attempt to answer that question. Maybe it's unanswerable in practice. But the examples of aliasing optimizations always seem to be eliminating a load, which in my experience is not an especially impactful thing in the average userspace widget written in C++. The closest example of a more sophisticated aliasing optimization I've seen is example 18 in this paper: https://dl.acm.org/doi/pdf/10.1145/3735592 https://dl.acm.org/doi/pdf/10.1145/3735592 ...but that specific example with a pointer passed to a function seems analogous to what is possible with 'restrict' in C. Maybe I misunderstood it. This is an interesting viewpoint, but is unfortunately light on details: https://lobste.rs/s/yubalv/pointers_are_complicated_ii_we_need#c_qh9swb https://lobste.rs/s/yubalv/pointers_are_complicated_ii_we_ne... Don't get me wrong, I'm not saying aliasing is a big conspiracy :) But it seems to have one of the higher hype-to-reality disconnects for compiler optimizations, in my limited experience.
      - Measter 10mo ago
        Back in 2015 when the Rust project first had to disable use of LLVM's `noalias` they found that performance dropped by up to 5% (depending on the program). The big caveat here is that it was miscompiling, so some of that apparent performance could have been incorrect. Of course, that was also 10 years ago, so things may be different now. There'll have been interest from the Rust project for improving the optimisations `noalias` performs, as well as improvements from Clang to improve optimisations under C and C++'s aliasing model.
        jcalvinowens 10mo ago
        Thanks! I've heard a lot of anecdotes like this, but I've never found anyone presenting anything I can repeoduce myself.
- jawilson2 10mo ago
  > C++ exceptions have huge overhead when actually thrown Which is why exceptions should never really be used for control flow. In our code, an exception basically means "the program is closing imminently, you should probably clean up and leave things in a sensible state if needed." Agree with everything else mostly. C/C++ being a "thin layer on top of hardware" was sort of true 20? 30? years ago.
- pjmlp 10mo ago
  CUDA hardware is specially designed against C++ memory model. It wasn't initially, and then NVIDIA went through a multi-year effort to redesign the hardware. If you're curious, there are two CppCon talks on the matter.
colonwqbang 10mo ago
Your post could be (uncharitably) paraphrased as: "once you have written correct C++ code, the drawbacks of C++ are not relevant". That is true, and the same is true of C. But it's not really a counterargument to Rust. It doesn't much help those us who have to deliver that correct code in the first place.

amluto 10mo ago

> C++ maps almost perfectly to the hardware with minimal overhead Barely. The C++ aliasing rules map quite poorly into hardware. C++ barely helps at all with writing correct multithreaded code, and almost all non-tiny machines have multiple CPUs. C++ cannot cleanly express the kinds of floating point semantics that are associative, and SIMD optimization care about this. C++ exceptions have huge overhead when actually thrown.

wrathofmonads 10mo ago
In simulations or in game dev, the practice is to use an SoA data layout to avoid aliasing entirely. Job systems or actors are used for handling multithreading. In machine learning, most parallelism is achieved through GPU offloading or CPU intrinsics. I agree in principle with everything you’re saying, but that doesn’t mean the ecosystem isn’t creative when it comes to working around these hiccups.
jcalvinowens 10mo ago
> The C++ aliasing rules map quite poorly into hardware. But how much does aliasing matter on modern hardware? I know you're aware of Linus' position on this, I personally find it very compelling :) As a silly little test a few months ago, I built whole Linux systems with -fno-strict-aliasing in CFLAGS, everything I've tried on it is within 1% of the original performance.
- amluto 10mo ago
  Even with strict aliasing, C and C++ often have to assume aliasing when none exists.
  - jcalvinowens 10mo ago
    If they somehow magically didn't, how much could be gained? I've never seen an attempt to answer that question. Maybe it's unanswerable in practice. But the examples of aliasing optimizations always seem to be eliminating a load, which in my experience is not an especially impactful thing in the average userspace widget written in C++. The closest example of a more sophisticated aliasing optimization I've seen is example 18 in this paper: https://dl.acm.org/doi/pdf/10.1145/3735592 https://dl.acm.org/doi/pdf/10.1145/3735592 ...but that specific example with a pointer passed to a function seems analogous to what is possible with 'restrict' in C. Maybe I misunderstood it. This is an interesting viewpoint, but is unfortunately light on details: https://lobste.rs/s/yubalv/pointers_are_complicated_ii_we_need#c_qh9swb https://lobste.rs/s/yubalv/pointers_are_complicated_ii_we_ne... Don't get me wrong, I'm not saying aliasing is a big conspiracy :) But it seems to have one of the higher hype-to-reality disconnects for compiler optimizations, in my limited experience.
    - Measter 10mo ago
      Back in 2015 when the Rust project first had to disable use of LLVM's `noalias` they found that performance dropped by up to 5% (depending on the program). The big caveat here is that it was miscompiling, so some of that apparent performance could have been incorrect. Of course, that was also 10 years ago, so things may be different now. There'll have been interest from the Rust project for improving the optimisations `noalias` performs, as well as improvements from Clang to improve optimisations under C and C++'s aliasing model.
      - jcalvinowens 10mo ago
        Thanks! I've heard a lot of anecdotes like this, but I've never found anyone presenting anything I can repeoduce myself.
jawilson2 10mo ago
> C++ exceptions have huge overhead when actually thrown Which is why exceptions should never really be used for control flow. In our code, an exception basically means "the program is closing imminently, you should probably clean up and leave things in a sensible state if needed." Agree with everything else mostly. C/C++ being a "thin layer on top of hardware" was sort of true 20? 30? years ago.
pjmlp 10mo ago
CUDA hardware is specially designed against C++ memory model. It wasn't initially, and then NVIDIA went through a multi-year effort to redesign the hardware. If you're curious, there are two CppCon talks on the matter.

colonwqbang 10mo ago

Your post could be (uncharitably) paraphrased as: "once you have written correct C++ code, the drawbacks of C++ are not relevant". That is true, and the same is true of C. But it's not really a counterargument to Rust. It doesn't much help those us who have to deliver that correct code in the first place.