Scientific computing and parallel computing C++23/C++26

[Ola Fosheim Grøstad]

On Tuesday, 18 January 2022 at 20:28:52 UTC, bachmeier wrote:
> from rewriting a plotting library from scratch. It's not common 
> that you're plotting 100 million times for each run of your 
> program.

It is not uncommon to interact with plots that are too big for 
matplotlib to handle well. The python visualization solutions are 
very primitive. Having something better than numpy+matplotlib is 
obviously an advantage, a selling point for other offerings.

Having the exact same thing? Not so much.

> You can replace the pieces where it makes sense to do so. The 
> goal of the D program is whatever analysis you're doing on top 
> of those libraries, not the libraries themselves.

You don't get a unified API with good usability by collecting a 
hodge podge of libraries. You also don't get any performance or 
quality advantage over other solutions. Borrowing is ok, 
replicating APIs? Probably not. What is then the argument for not 
using the original language directly?

The reason for moving to a new language (like Julia or Python) is 
that you get something that better fits what you want to do and 
that transitioning provides a smoother work flow in the end.

If everything you achieve by switching is replacing one set of 
trade offs with another set of trade offs, then you are generally 
better off using the more mainstream, supported and well 
documented alternative.

So where do you start? With a niche, e.g. signal processing or 
some other "mainstream" niche.


> We call C libraries all the time. Nobody thinks that's a 
> problem. A bunch of effort has gone into calling C++ libraries 
> and there's tons of support for that effort.

So, libraries are often written in C in order to support other 
languages and they are structured in a very basic way as far as C 
code goes. C-only libraries are sometimes not as easy to 
interface with as they rely heavily on macros, dedicated runtimes 
or specifics of the underlying platform.

I also think the C++ interop D offers is a bit clunky. It is more 
suitable for people who write C-like C++ than people who try to 
write idiomatic C++. D has to align itself more with C++ 
semantics for this to be a good selling point.

I am somewhat impressed that Python has many solutions for 
binding to C++ though, even when Python is semantically a very 
poor fit for C++… (e.g. 
[Binder](https://github.com/RosettaCommons/binder)). D's 
potential strength here is not so much in being able to bind to 
C++ in a limited fashion (like Python), but being able to port 
C++ to D and improve on it. To get there you need feature parity, 
which is what this thread is about.

We now know that C++ will eventually get more powerful parallel 
computing abilities built into the language, supported by the 
hardware manufacturer Nvidia for their hardware (nvc++). That 
said Apple has shown little interest in making their versino of 
C++ work well with parallel computing and the C++ standard lib is 
not very good for numeric operations. Like, the simd code I wrote 
for inner product (using generic llvm SIMD) turned out to be 3 
times faster than the generic C++ standard library solution.

Yet, we see *"change is coming"* written on the horizon, I think.

So either D has to move in a different direction than competing 
head-to-head with C++ or one has be more strategic in how the 
development process is structured. Or well, just more strategic 
in general.