What are new c++20 features that are relevant to scientific computation?

Question

In my research department we plan a small seminar on the new c++20 language standard. There are exhaustive lists online presenting the new features of the language standard, some of which will be of interest to this community, some will be inconsequential.

I think I understand the advantages of:

• concepts (wiki) - clearer definition of (template-) interfaces within codebases and less cryptic errors in template resolution. We may explicitly state what a templated type should bring, reducing the need for duck-typing.
• keywords: [[likely]] and [[unlikely]] - tell the compiler how to do branch prediction!
• modules - collect headers in a module (fortran-style), (hopefully) helping in better include management and improved compilation times
• ...?

From the perspective of numerical computation, what are other c++20 features that are particularly useful?

Answer 1

• Feature test macros: HPC is generally stuck on old compilers or compilers with partially conformant implementations. This can help ease the pain of working on the custom architectures common in HPC. Example:

#ifdef __cpp_lib_source_location
#include <source_location>
#endif
...
#ifdef
auto sl = std::source_location();
std::cerr << "Error at line " <<  sl.line() << " of file " << sl.file_name() << "\n";
#else
std::cerr << "Error at line " << __LINE__ << " of file " << __FILE__ << "\n";
#endif

• While we're at it, I really like the source_location header; I've personally been reimplementing this same functionality over and over. In scientific computing I find it particularly relevant, since a properly written error message that can take you directly to the source line where the proper error occurred is invaluable.

• Math constants: No more 4*arctan(1) for pi; use std::numbers::pi;.

• Atomic floating point ops. Very useful for (say) multithreaded Monte-Carlo integration.

• I have not read the stop_token proposal, but near as I can tell it could be very useful. I once worked in a shop where the scicomp was all multithreaded and produced visualizations while the computation was ongoing, and what you learn when you can watch your simulation is that about 90% of the computations you start are for some reason or another bad; maybe the question is stupid or the parameters lead to unreasonable compute. So having a graceful way to cancel is very useful.

• The ranges library. Very excited to be able to use all the standard library algorithms on "arrays of structs" using projections.

• Another use for concepts is to prevent performance bugs. If I say an algorithm should work on a RandomAccessContainer and you pass in an std::list, pre-C++20 it should compile because std::list has a dereference operator []. But maybe it would turn an $O(1)$ algorithm into an $O(n)$, or an $O(n)$ to an $O(n^2)$.

• We also will be able to use Greek letters as identifiers. This might make mapping papers to code a bit easier.

Answer 2

C++ is a general purpose programming language, and consequently the improvements that are made in successive standards are, by and large, not particularly geared towards scientific computing but to the general ease of programming complex software.

That said, there are a few features that I can see as quite useful in scientific software:

• For a variety of reasons, many scientific software packages are heavily templated. Concepts will make writing such packages easier, and easier to debug.

• std::span is a useful abstraction for software that allocates memory in large chunks and then interprets it in specific ways. This is certainly going to make interfaces with older software easier (think in particular with Fortran software).

I think that C++17 was actually the bigger step, in particular because of this:

• A lot of std functions in C++17 have gotten overloads where the first argument is an ExecutionPolicy. See, for example, std::foreach. This enables better use of today's multicore machines.

There are also post-C++20 improvements that will be interesting to use. These are currently part of the "Parallelism v2 Technical Specification". An example is the ability to queue tasks together using std::experimental::future::then(). This is going to make it substantially simpler to write task-graph-based codes.