|
|
|
|
|
|
by Neywiny
260 days ago
|
|
|
I guess my point is that truly performant python code, at least for number crunching, uses vectorized numpy functions instead of loops, and the overhead on type checking for those is fairly minimal. I have a PR in on a compute heavy python program that I tried using numba to jit. Timing was within margins on using numpy and numba (even though the numba code could exit the loop early, which was why I was trying it) except with numba I'd be adding a dependency and it's more work to maintain the algorithms myself instead of relying on numpy. I think of the JS code I've seen, it's mostly written in JS. So making JS faster makes JS faster. With python, the fast code is written outside python. It's too late by like 20 years. The world won't rewrite itself into native python modules |
|
|
Well, yeah; the underlying C code assumes the type that was described to it by the wrapper (via, generally, the .dtype of an array), so it's O(1).
But I do wonder what the experience of Numpy has been like for the PyPy users.