Speed-up for loops

[BartC]

"Steven D'Aprano" <steve at REMOVE-THIS-cybersource.com.au> wrote in message 
news:4c83b425$0$28657$c3e8da3 at news.astraweb.com...
> On Sun, 05 Sep 2010 12:28:47 +0100, BartC wrote:

>> 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?

I've thought about it (writing an independent interpreter). But I don't know 
enough of the language, and a lot of it I don't understand (eg. OOP). 
Besides, I think the language itself deliberately makes it difficult to get 
it up to speed. Some of the reasons might be the ones set down here, in 
Chapter 2:

http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf

(Instead, I've confined my efforts to my own projects; the last interpreter 
I worked on did in fact get within a magnitude of C in performance, without 
using JIT or other fancy tricks.)

> 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.

I don't know, there's seem to be an awful lot of effort going into 
addressing exactly this issue (eg. PyPy, Pscyo, Unladen Swallow, 
Shedskin....)

> 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:

OK, you're saying there's no point in reducing the loop overhead, because 
the loop body is going to be even slower.

All those compilers that offer loop unrolling are therefore wasting their 
time...

-- 
Bartc