Re:Does C++ still deserve a bad rap?
by quietbritishjim on Saturday October 17, 2020 @05:24AM
(#24808741)
The comment that started this discussion is about the specific case that most of your execution time is in libraries rather than your application code. In that Python is usually no slower to execute than C/C++. You disagreed with that by claiming that such programs cannot be multi threaded because of that GIL, and I just corrected that because it's untrue (edit: it's untrue in general, but especially untrue in this situation we're talking about).
To be honest I'm not sure what your new comment is about. If you're saying that Python is not necessarily faster than C then I'm sure no one going to dispute that; in the situation we're discussing, the performance of your code is totally dependant on the efficiency of the libraries that are doing all the work, not your glue code. If you're saying that Python is slower than C when it's doing a non-trivial amount of the execution, then sure, but no one was claiming that either. Or maybe you just want to simplistically categorise languages as "performat" and "non-performant" without thinking about the specific contexts they can be used in, but that wouldn't make any sense. Did I misunderstand?
In that corner case you still have slow Python glue code calling fast C++ code.
It makes no sense to claim that Python is performant based on the idea that it may be used to glue together calls to performant C++ code, while ignoring the fact that not only Python forces performance restrictions on it's code but also that C++ code is quite capable of calling performant C++ code itself.