Python's biggest compromises

[John Roth]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:MM7ikWAxZoK$Ew0N at jessikat.fsnet.co.uk...
> In article <vikh3ink3djc7c at news.supernews.com>, John Roth
> <newsgroups at jhrothjr.com> writes
> >>
> >> I don't have any data here, but I believe Python is just a little too
> >> weakly typed for compiling to float*float type assembler efficiently.
> >
> >The trick with JITs is that they don't depend on absolute type
> >consistency. They depend on the observation that 99.44% of your
> >code is type consistent, and that consistency will turn up at run time.
So
> >the code they generate depends on that discovered consistency, and
> >checks in front of each section to discover if the types are what the
> >code expects.
> >
> >If it is, they execute it, if it isn't, they abandon it and go back to
> >the intepreter to discover what happened.
> >
> >John Roth
> Yes I suspected they have to do that, but that implies that a discovered
> 'float' object must carry along a whole lot of baggage (I guess I mean
> be a more generic object) to allow for the testing. Loops without method
> or function calls would be good candidates for JIT as methods and
> functions could alter attribute types.
>
> Is the JIT object literally just a union of
>
>         type,values
>
> or would it be an actual Python object? For example would an
> innerproduct be over a pair of lists or would the magic convert these
> into actual double arrays.

As far as I'm aware, the JIT code doesn't fiddle with the data;
it just does the equivalent of assert tests at the beginning of the
blocks to verify that it's got the type of object it expects.

In other words, it does a very large amount of run-time type
checking. This only pays off if it can save even more expense
by compiling the code.

Now, this is going to be difficult for short segments of code,
but it can be quite a time saver if the JIT generated code can
make intermediate objects vanish so they don't have to be
created just to be discarded a short time later.

John Roth

> -- 
> Robin Becker