News for hackers. Stuff that matters.
Re:NumPy Illustrated: The Visual Guide to NumPy by Chris_Newton on Tuesday December 29, 2020 @02:28PM (#25573735)
If Python was a good scientific programming language, the most natural way to implement scipy/numpy and all that would be using Python itself, but this is not at all the case.

To be fair, with modern hardware capabilities, I still wouldn’t be writing out linear algebra algorithms in the language itself even if I were programming in a relatively low-level language like C or C++. I’d be using an implementation of BLAS/LAPACK or some other suitable library, which in turn might well have been written in carefully tuned assembly language on the target platform in order to use any parallel or otherwise specialised operations provided by a CPU or GPU, partition data for optimal cache use, etc.

The situation with numpy and other numerical libraries in Python seems analogous. We are still importing highly optimised code to do the numerical heavy lifting and then using a higher-level language to write the less performance-sensitive logic and glue everything together conveniently.

Re:NumPy Illustrated: The Visual Guide to NumPy by dunefox on Wednesday December 30, 2020 @07:59AM (#25581265)
But as soon as you actually need to implement an efficient library you must use C/C++/Fortran. Julia, for example, allows you to stay in Julia and get comparable performance.
Re:NumPy Illustrated: The Visual Guide to NumPy by rbanffy on Wednesday December 30, 2020 @10:51AM (#25582685)
If you need to implement an efficient vector math library on modern hardware you'll end up using intrinsics, padding structures for cache alignments, identifying which CPU, GPU, NPU, and vector extensions you are running on to better use specific features, and so on, and it won't look like idiomatic sequential C/C++/Fortran for almost every value of "idiomatic".