3 ms·

You don't have direct control over caches, however if you have control over memory layout you can indirectly influence how the code performs by leveraging the p

You don't have direct control over caches, however if you have control over memory layout you can indirectly influence how the code performs by leveraging the proper cache sizes/lanes. If that's your goal, you cannot focus on program flow alone, and that's the main point. Low-level and high-performance code is not "pretty" by modern standards, as it often requires DMA and tight control over data placement in order to fully leverage instruction-level and hardware-level parallelism. The hardware influences how the data structure layout should be first, and we work on top of it. We abstract structs and containers that capture this layout, so that we can still have a readable program flow at the end. In this sense, C++ can still be used as a glorified assembler, without the need to drop down to ASM for the simple stuff as your for loop: nobody wants to do that (me included). But contrarily to C, you can avoid a ton of preprocessor macros and get improved type checking, while still using ASM in selected spots if needed. Your example about vector<bool> is not really surprising. Do you want the iterator to be efficient, or consistent? Tough choice, depending on the scenario. It's annoying that it's not standardized in one form or the other. I remember I was fretting over this detail over 10 years ago, but in actuality I used vector<bool> exactly 0 times in my career so far. Again, please don't consider this as if I was praising C++. There are _many_ areas, including lack of standardization in the stdlib area (vector<bool> being one of many), that I don't like. I just want to say that it's an incredibly versatile tool which is very hard to replace given the same constraints.

jnxx 6y ago
> Low-level and high-performance code is not "pretty" by modern standards, as it often requires DMA and tight control over data placement in order to fully leverage instruction-level and hardware-level parallelism. This is true if you look at implementations like these: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... for example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-rust-8.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... vs. https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-gpp-4.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I'd say the C++ code in this particular case is not only much longer but also uglier. However, how much of a fraction of C++ code in use does really require direct control over DMA calls? If you could get an at least equally fast result as when writing "normal C++" in Rust, with more safety and less effort for debugging, would this not be tempting for many people using C++? Because this is what I observed in my case. And this given that I've written no more than a few hundred lines of performance-critical code in Rust, and have worked for > 10 years on performance-critical code in C++ and C.
jnxx 6y ago
> Your example about vector<bool> is not really surprising. Do you want the iterator to be efficient, or consistent? The thing is, what cppreference says here is that this innocent-looking code might either not compile or cause undefined behavior in whatever part of the program. In my case on GCC 8, it caused memory leak warnings with address sanitizer. For larger programs and especially for programs which have hard requirements on real-time latencies, safety or robustness, this is not acceptable. And yes, an experienced C++ developer will initially need a little more time to write the same code in Rust, compared to C++. (I do not think this is true for developers new to C++ because C++ is a very large language). However, in any larger program, the time spent for testing and debugging is very likely larger than the time spent for typing in the first code. And in this metric, Rust's strict approach to correctness is far better. And if you get to debug undefined behavior in large multi-threaded programs, the time you can spend debugging code is basically unbound if you were were not both experienced and careful with writing first.

jnxx 6y ago

> Low-level and high-performance code is not "pretty" by modern standards, as it often requires DMA and tight control over data placement in order to fully leverage instruction-level and hardware-level parallelism. This is true if you look at implementations like these: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... for example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-rust-8.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... vs. https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-gpp-4.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I'd say the C++ code in this particular case is not only much longer but also uglier. However, how much of a fraction of C++ code in use does really require direct control over DMA calls? If you could get an at least equally fast result as when writing "normal C++" in Rust, with more safety and less effort for debugging, would this not be tempting for many people using C++? Because this is what I observed in my case. And this given that I've written no more than a few hundred lines of performance-critical code in Rust, and have worked for > 10 years on performance-critical code in C++ and C.

jnxx 6y ago

> Your example about vector<bool> is not really surprising. Do you want the iterator to be efficient, or consistent? The thing is, what cppreference says here is that this innocent-looking code might either not compile or cause undefined behavior in whatever part of the program. In my case on GCC 8, it caused memory leak warnings with address sanitizer. For larger programs and especially for programs which have hard requirements on real-time latencies, safety or robustness, this is not acceptable. And yes, an experienced C++ developer will initially need a little more time to write the same code in Rust, compared to C++. (I do not think this is true for developers new to C++ because C++ is a very large language). However, in any larger program, the time spent for testing and debugging is very likely larger than the time spent for typing in the first code. And in this metric, Rust's strict approach to correctness is far better. And if you get to debug undefined behavior in large multi-threaded programs, the time you can spend debugging code is basically unbound if you were were not both experienced and careful with writing first.