On Sun, 05 Sep 2010 12:28:47 +0100, BartC wrote: >> Getting the above kind of code fast requires the interpreter to be >> clever enough so that it will use native machine operations on a int >> type instead of converting back and forth between internal >> representations. > > Writing for i in xrange(1000000000) you'd think would give it a clue, > but it makes no difference.
CPython takes a very conservative view towards runtime optimizations. Optimizations don't happen for free, you know, they have costs. Memory is one cost, but human time and effort is another. But if you want a JIT compiler, see Psycho, or try PyPy, which is very exciting and I hope will one day be ready to take over from CPython as the first choice for production use. [...] > One order of magnitude (say 10-20x slower) wouldn't be so bad. That's > what you might expect for a dynamically typed, interpreted language. > > But on my machine this code was more like 50-200x slower than C, for > unaccelerated Python. I'd say that 50-200 times slower than C is exactly what I'd expect from a dynamically typed language like Python without any fancy JIT tricks. Getting such a language to within an order of magnitude of C is quite an achievement. >> Generally, you use matlab's vectorized operations, and in that case, >> numpy gives you similar performances (sometimes faster, sometimes >> slower, but in the same ballpark in general). > > That would simply be delegating Python to a scripting language. That's sheer unadulterated nonsense. In any case, Python was designed as a glue language, specifically to be a high-level user-friendly language for gluing components written in C together. That's what Python *is* -- it provides a bunch of primitives, written in C (or Java, or dot-Net, pick whichever implementation you like) and manipulated in a friendly, safe language. Calling numpy for fast vectorized operations is *exactly* the right solution, if you need high-performance maths calculations. Use the right tool for the job, don't insist that your spanner should double as a screwdriver. > It would > be nice if you could directly code low-level algorithms in it without > relying on accelerators, and not have to wait two and a half minutes (or > whatever) for a simple test to complete. Yes, and it would be nice if my clothes washed and ironed themselves, but they don't. Somebody has to do the work. Are you volunteering to write the JIT compiler for CPython? Will you contribute to the PyPy project, or help maintain Psycho, or are you just bitching? The simple fact is that there are far more important things for Python developers to spend their time and effort on than optimizations like this. If such an optimization comes out of the PyPy project, I'll be cheering them on -- but it's a lot of effort for such a trivial gain. The example given by the Original Poster is contrived. Nobody sensibly writes an integer multiplication as a repeated addition like that, and any real code that would need to be put in a for loop is almost certainly going to be too complicated for the JIT compiler to benefit greatly. The loop overhead itself will almost certainly be overwhelmed by the work done in the loop: [st...@sylar ~]$ time python -c "a = 0 > for i in xrange(10000000): > a += 10 > " real 0m6.906s user 0m5.820s sys 0m0.022s which is about double the time for an empty loop of the same size. -- Steven -- http://mail.python.org/mailman/listinfo/python-list