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

[jmh530]

On Tuesday, 18 January 2022 at 21:22:11 UTC, H. S. Teoh wrote:
> [snip]
>
> +1.  Why do we need to reinvent numpy/scipy? One of the 
> advantages conferred by D's metaprogramming capabilities is 
> easier integration with other languages.  Adam Ruppe's jni.d is 
> one prime example of how metaprogramming can abstract away the 
> nasty amounts of boilerplate you're otherwise forced to write 
> when interfacing with Java via JNI. D's C ABI compatibility 
> also means you can leverage the tons of C libraries out there 
> right now, instead of waiting for somebody to reinvent the same 
> libraries in D years down the road.  D's capabilities makes it 
> very amenable to being a "glue" language for interfacing with 
> other languages.
>
>
> T

I'm all for leveraging C libraries in D, but if you have code 
that needs to be performant then you may run into limitations 
with python. If you're building one chart with Matplotlib, then 
it's probably fine. If you have some D code that takes longer to 
run (e.g. a simulation that deals with a lot of data and many 
threads), then you might be a little more careful about what 
python code to incorporate and how. I don't know the technical 
details needed to get the best performance in that situation (are 
there benchmarks?), but I saw some work done about using python 
buffer protocol when calling D functions from python.

In addition, the python code might itself be calling the same C 
libraries that D can (e.g. LAPACK) (though potentially with 
different defaults, trading off performance vs. accuracy, 
resulting in python being faster in some cases than D). In that 
case, python is also a glue language. Taking the same approach in 
D can simplify your code base a little bit and you don't need to 
worry about any additional overhead or limitations from GIL that 
might get introduced.

Again, not something you need to worry about when performance is 
not a big issue.