To do that you first need to have a way of extending JavaScript with C and/or Fortran. No way numpy can be implemented in pure js or python without being excruciatingly slow.
I think Numpy is written in C, so in principle they could use the same approach for JS (and invoke SIMD functions from C). The problem, however, is that there is no operator overloading in JS. So you can't write things like a[:,:,3] *= 2.
So rather than spend 10-20 minutes reading about numpy, the author wrote 3 other implementations...?
The fact that they ran the C code without the optimisation flags and compared it that way makes me think Javascript was what they actually wanted to write this one in anyway.
The core of numpy is written in C, with some unfortunate dependencies on the C Python API. It should be possible to extract the C core of numpy (with some additional work) and wrap it in Javascript or Lua.
It doesn't sound like OP is working on something that needs NumPy, and if he did, I don't see why he couldn't write a small script in Python to be called by the existing codebase.
But javascript does not have something like numpy. You can easily get one to two orders of magnitude faster using numpy when applicable, and a MP3 decode certainly falls in that category.
NumPy has lots of C calls, and the functionality has to be implemented entirely with the language features. What you are suggesting is outside the scope of the paper.
Thank you! So this looks interesting but it seems like there's no easy way to share numpy arrays?
The main use case for a language other than python is a more robust codebase but also performance. We need to be able to efficiently ship lots of large arrays between the languages and the Rust-Python interop supports zero copy arrays for example.
Interesting. Numpy within python does give near native speeds for number crunching though does it not? Copying around arrays does feel like an area where python suffers, however.
reply