compiled python speed

[clarkclark]

I've been wondering about python's compile process.

For python benchmark stats, i've heard numbers like 30,40 or 50 times slower than c. This is a bit strange, because much of python could be ported rather directly into c++, which is only marginally slower than c... Is the reason for the lethargy rooted in the quick compile time of python, and lack of compile-time optimizations thereby?

If anyone knows the answer to this (or a reason that this question is flawed), please respond.

Thanks,
-Clark

 

[WebDrake]

OK, I'm a beginner with Python so my reply here is to an extent of curiosity (hoping to spark off some interesting discussion) than out of authority. Please correct with good grace and do not flame.

Python is an interpreted language---right?---which from what I understand never compiles fully to machine code, but rather to an intermediate language (bytecode?) whose commands are translated into machine commands by the Python virtual machine. That's why Python compiles fast---because it does not have to be translated all the way down into machine code---but of course there's a speed hit.

I get the impression, too, that there's a strong tradeoff between the speed of a programming language and its notational elegance (I'd be interested if any more experienced programmers could comment on this). LISP is slow for this reason. By contrast C, which is superficially rather ugly, is fast, because what you do with C is really only a pretty way of writing what the computer hardware is doing---shooting different numbers about between different memory addresses. If you want to write really fast code, you can write your program direct in assembly language---you will be talking pretty much direct to the computer in its own language and can therefore write in such a way that is most simple for that particular hardware to deal with---but it will be horribly ugly (and therefore a nightmare to debug), as well as being near-impossible to port.

I have a sneaky suspicion that while, as you say, much of Python could be ported to C++, it's those little bits of extra elegance and flexibility that make the difference. After all, as far as languages go, C++ is still fairly ugly and inexpressive. The fact that Python is beautiful for us poor dumb humans, who tend to work with concepts and relationships, makes it pretty foreign and alien to your poor old Pentium, which thinks of things in terms of shuffling around strings of 1's and 0's between different memory locations.

But the bottom line is that benchmark stats by themselves give only a superficial picture of what one might want in a language. The real question to ask is not "How fast is this language?" but "Will it solve the task I want to solve?" For example, you cite C++ as being only "marginally slower" than C, which in general is true. But for much of the work I do---large-scale number crunching for scientific problems---that margin becomes very wide and there is a significant performance hit to be had from using C++. I suspect that I could gain even further performance improvement by forgoing C for FORTRAN, although colleagues in the know have told me that these days the compilers are so good that the difference is negligible.

For other colleagues of mine, the high-end number crunching is slightly less important and they are more productive using C++ because it allows them to code faster and more elegantly while still achieving their required computational goals. Others use Java, which is slower but more elegant (and portable) still, and this is what it comes down to---a tradeoff between a satisfactory performance level and a satisfactory speed of code writing, debugging and distribution. For a great deal of desktop applications sheer number crunching power is not an urgent requirement. What is important is being able to easily understand and update the code and add new features, to be able to remove errors quickly, and to minimise the effort required to adapt the program to work on different hardware setups. This is where Python excels.

-- Joe

 

[rzs0502]

I don't believe Python is that much slower (up to 50x slower than C)
But I guess it also depends on the size and complexity of the program.
I found this site interesting regarding language benchmarks.

http://shootout.alioth.debian.org/

You'll find that Python is one of the top performers (and that's without the psyco module)


"If you always do what you've always done, you will always be where you've always been."

 

[WebDrake]

I don't believe Python is that much slower (up to 50x slower than C)

It also almost certainly depends on how you go about coding. I would imagine that if you just copy C code almost literally into Python it really screws up the performance.

By analogy, think about MATLAB, a scripting language for easy mathematical programming (primarily linear algebra) and data plotting. Suppose I want to calculate the dot product of two vectors (arrays), x and y. In C I write,

dp = 0;
for(i=0;i<N;++i)
    dp += x[i]*y[i];

... but if I copy that sequence of commands literally into MATLAB,

dp = 0;
for i=1:length(x)
    dp = dp + x(i)*y(i);
end

... it becomes Really Really Slow, nightmarishly so if the arrays are large. By contrast if I ask for the dot product using idiomatic MATLAB syntax,

dp = x'*y;

it is not only much briefer, but much, much faster, because MATLAB's interpreter can translate the latter command into one internal operation, whereas the former code consists of setting up a sequence of commands which are each separately sent to the interpreter---a nightmare!

I would guess that similarly, writing properly "Pythonic" code must matter a great deal in terms of getting good performance.