Speaking of python performance, I recently benchmarked "numpy vs js" matrix multiplication performance, and was surprised to find js significantly outperforming numpy. For multiplying two 512x512 matrices: python numpy: ~3.30ms numpy with numba: ~2.90ms node tfjs: ~1.00ms gpu.js: ~4.00ms ndarray: ~118.00ms vanilla loop: ~138.00ms mathjs: ~1876.00ms browser tfjs webgpu: ~.16ms tfjs webgl: ~.76ms tfjs wasm: ~2.51ms gpu…
TensorFlow.js matrices are immutable, which puts more restrictions on your programming style that standard Numpy. You cat get immutable, GPU-enhanced matrices for Python, too.
Numpy runs on CPU. Tfjs runs on GPU. Not a fair comparison.
You're right, it's not a fair comparison -- I think it's still interesting though, since numpy is the standard people would reach for, which made me think it would be the fastest / use the GPU. I expect a python library that uses the GPU would be just as fast as the others.
It adds a great deal of complexity (and often user frustration) for a Python package to support both CPU and GPGPU.
Syntactically Python is great. Runtime though, its not. Its fast to code in - that is all.
Agreed. I'm past the "it's like writing pseudo-code - so cool!" honeymoon phase and onto the "some sort of static typing is actually pretty useful" as a developer.
Numpy runs on CPU. Tfjs runs on GPU. Not a fair comparison.
You're right, it's not a fair comparison -- I think it's still interesting though, since numpy is the standard people would reach for, which made me think it would be the fastest / use the GPU. I expect a python library that uses the GPU would be just as fast as the others.
For that, you can use cupy[0], PyTorch[1] or Tensorflow[2]. They all mimic the numpy's API with the possibility to use your GPU.
Agreed. I'm past the "it's like writing pseudo-code - so cool!" honeymoon phase and onto the "some sort of static typing is actually pretty useful" as a developer.
No such thing as a constant in Python. You can optionally name a variable in uppercase to signal to others that it should be, but that's about it. You can write a new compiler if you'd like, as detailed on this page. But CPython doesn't work that way and 99% of the ecosystem is targeted there. There is some work on making more assumptions as it runs, now that the project has funding. This is about where my off-top-of…
> No such thing as a constant in Python. You can optionally name a variable in uppercase to signal to others that it should be, but that's about it. Yeah that’s the point - the JIT takes that capitalisation as a hint to treat it as a true constant and bake the value in until it’s redefined. This is all solved stuff and isn’t a barrier to implementing a powerful JIT for Python if someone wanted to.
It's solved stuff in languages other than Python. Many groups even at google have tried and failed.
> No such thing as a constant in Python. You can optionally name a variable in uppercase to signal to others that it should be, but that's about it. Yeah that’s the point - the JIT takes that capitalisation as a hint to treat it as a true constant and bake the value in until it’s redefined. This is all solved stuff and isn’t a barrier to implementing a powerful JIT for Python if someone wanted to.
It's solved stuff in languages other than Python. Many groups even at google have tried and failed.
No, we know how to optimise all these issues. They're solved, through a combination of online profiling, inline caching, splitting, deoptimisation, scalar replacement, etc. (I wrote a PhD on it.) I don't think you could name a single Python language feature that we don't know how to optimise efficiently. (I'd be interested if you could.) But implementing them all is a difficult engineering challenge, even for Google, mainly because it involves storing a lot of state in a system that isn't designed to have state attached everywhere.
No, its better. You can build the code first, test that it functions as expected, then add types, then compile it. This is miles ahead of having to struggle with getting types correct in C++ before you even have anything resembling a workable solution.
I don't disagree but I wish Python had builtin support for runtime type checking. I've thought about switching to Go or Rust for certain projects but Python's rich ecosystem makes it hard for me to switch, so for now I long for runtime type checking without needing an external library (e.g typeguard).