this post was submitted on 13 Jul 2024
112 points (98.3% liked)
Programming
17313 readers
261 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Unless the C++ code was doing something wrong there's literally no way you can write pure Python that's 10x faster than it. Something else is going on there. Maybe the c++ code was accidentally O(N^2) or something.
In general Python will be 10-200 times slower than C++. 50x slower is typical.
Nope, if you're working on large arrays of data you can get significant speed ups using well optimised BLAS functions that are vectorised (numpy) which beats out simply written c++ operating on each array element in turn. There's also Numba which uses LLVM to jit compile a subset of python to get compiled performance, though I didnt go to that in this case.
You could link the BLAS libraries to c++ but its significantly more work than just importing numpy from python.
Numpy is written in C.
Numba is interesting... But a) it can already do multithreading so this change makes little difference, and b) it's still not going to be as fast as C++ (obviously we don't count the GPU backend).
So you get the best of both worlds then: the speed of C and the ease of use of Python.
Sure but that's not relevant to the current discussion. The point is that removing the GIL doesn't affect Numpy because Numpy is written in C.