This is a fascinating subject. Firstly: a lot of people think that C (or C++) is faster than python, yes I agree, >
if you look at raw execution speed, then this is absolutely correct. The reasons for this are many and complex, but people who use this as a standalone reason to avoid Python almost always don't actually understand the subject too well. If you want to read more about this, I would recommend searching for "python glue language" for example: https://numpy.org/devdocs/user/c-info.python-as-glue.html > *Is there another explanation ?* > Yes, the people who wrote numpy implemented sum() 'better' than you did. That's not a put-down or anything, just an interesting reason why Python as a glue language works so well. Lots of very smart people spend a lot of time making numpy fast, because lots of people rely on it being fast (partly because raw Python is a bit too slow to do these sorts of things natively). In C/C++ it's easy to say: 'it's just a for-loop, let's write it the simple way'. 9 times out of 10, the for loop will be much faster than you ever need it to be in either language, but if you really need speed for whatever reason, you're going to have to reach for a library. Numpy's popularity means that everyone knows to just use it for this sort of thing (interestingly, if you have a GPU, using something like pytorch might be much faster here, depending on data transfer overheads). In C/C++ there are many many libraries that can do this sort of thing, but none have the same general appeal as Numpy (in my opinion). This means that with Python, you write the simple bits in a nice dynamic, easy to write language, and the hard bits get farmed out to libraries like numpy, and you benefit from some really awesome optimized code that make your code faster than the naive equivalent 'fast' C implementation. For example the following are all (i believe) different array sum implementations for different CPU vector features across different architectures/extensions: https://github.com/numpy/numpy/blob/b97e7d585de4b80ae8202c1028c0dc03f5dde4ef/numpy/core/src/common/simd/avx512/arithmetic.h#L353 https://github.com/numpy/numpy/blob/b97e7d585de4b80ae8202c1028c0dc03f5dde4ef/numpy/core/src/common/simd/sse/arithmetic.h#L327 https://github.com/numpy/numpy/blob/b97e7d585de4b80ae8202c1028c0dc03f5dde4ef/numpy/core/src/common/simd/neon/arithmetic.h#L283 It's absolutely possible to make C/C++ perform at the same speed as numpy, but you will have to invest a lot of time/effort in learning about performance programming to get there (this can be a really useful skill to learn, if you're interested!) Some anecdotes: 1. I was using a C data logger library for some data logger device that performed awfully, so I re-wrote it, feature-for-feature in python, and it was 100x faster. Why? Not because Python is faster than C, just that somewhere the original implementation had some bug/issue that was causing slowness (It was related to sqlite transaction handling, but the C code made it very hard to spot the issue, whereas the python was much easier to reason about). Nothing about what this library was doing required high-performance code, so using Python was not a speed issue at all. 2. I worked on a very large data processing application for a fortune 500 co in Python, one part of the input pipeline was never going to be fast enough for our volumes in pure python, so we wrote a custom module in Cython (A hybrid language that compiles to a C/C++ extension), this small module allowed the entire system to perform up to spec, and (along with a numpy-like library) meant we could implement a lot of custom business logic in Python, rather than in less expressive languages, and generally out-perform similar Java/other language systems. Steve
_______________________________________________ python-uk mailing list python-uk@python.org https://mail.python.org/mailman/listinfo/python-uk
