That completely depends on what you’re doing. If you’re doing tasks that python can completely offload to some highly optimised library written in C/C++/Fortran, then yes. However at that point you’re not really comparing Python to C anymore, but rather your C implementation to whatever library you used.
A fair comparison is to compare pure python to pure C, in which case you need to mess up the C-code pretty bad if Python is to stand a chance.
I do think, it’s fair to use Python code which uses C under the hood in benchmarks, because it does often match reality. But then it also has to be realistic code. If it’s just a single line of Python code, which calls into C and then everything happens there, then there is really no point for you to use Python.
Python only makes sense to use, if you do write some amount of glue code with it. And then it does require significantly more skill to write performant code than it does with many other languages, as lots of costly abstractions are hidden from you. And it often also requires more effort, since you might not find performant libraries, since so much of the ecosystem only has performance as an afterthought. Reality is messy, which is why realistic Python code still tends to do terribly in benchmarks, whether it calls into C or not.
100 % agree here. If you’re testing an actual use-case, it’s fair to compare realistic python to realistic C. However, I would argue that at that point you’re no longer benchmarking Python vs. C as languages, but Python vs. C for that particular use-case.
It might not be a language but a skill issue if your python code performs significantly worse than your C code
That completely depends on what you’re doing. If you’re doing tasks that python can completely offload to some highly optimised library written in C/C++/Fortran, then yes. However at that point you’re not really comparing Python to C anymore, but rather your C implementation to whatever library you used.
A fair comparison is to compare pure python to pure C, in which case you need to mess up the C-code pretty bad if Python is to stand a chance.
I do think, it’s fair to use Python code which uses C under the hood in benchmarks, because it does often match reality. But then it also has to be realistic code. If it’s just a single line of Python code, which calls into C and then everything happens there, then there is really no point for you to use Python.
Python only makes sense to use, if you do write some amount of glue code with it. And then it does require significantly more skill to write performant code than it does with many other languages, as lots of costly abstractions are hidden from you. And it often also requires more effort, since you might not find performant libraries, since so much of the ecosystem only has performance as an afterthought. Reality is messy, which is why realistic Python code still tends to do terribly in benchmarks, whether it calls into C or not.
100 % agree here. If you’re testing an actual use-case, it’s fair to compare realistic python to realistic C. However, I would argue that at that point you’re no longer benchmarking Python vs. C as languages, but Python vs. C for that particular use-case.