[Python-Dev] Python 3 optimizations continued...

[Cesare Di Mauro]

2011/8/31 stefan brunthaler <stefan at brunthaler.net>

> > I think that you must deal with big endianess because some RISC can't
> handle
> > at all data in little endian format.
> >
> > In WPython I have wrote some macros which handle both endianess, but
> lacking
> > big endian machines I never had the opportunity to verify if something
> was
> > wrong.
> >
> I am sorry for the temporal lapse of not getting back to this directly
> yesterday, we were just heading out for lunch and I figured it only
> out then but immediately forgot it on our way back to the lab...
>
> So, as I have already said, I evaluated my optimizations on x86
> (little-endian) and PowerPC 970 (big-endian) and I did not have to
> change any of my instruction decoding during interpretation. (The only
> nasty bug I still remember vividly was that while on gcc for x86 the
> data type char defaults to signed, whereas it defaults to unsigned on
> PowerPC's gcc.) When I have time and access to a PowerPC machine again
> (an ARM might be interesting, too), I will take a look at the
> generated assembly code to figure out why this is working. (I have
> some ideas why it might work without changing the code.)
>
> If I run into any problems, I'll gladly contact you :)
>
> BTW: AFAIR, we emailed last year regarding wpython and IIRC your
> optimizations could primarily be summarized as clever
> superinstructions. I have not implemented anything in that area at all
> (and have in fact not even touched the compiler and its peephole
> optimizer), but if parts my implementation gets in, I am sure that you
> could add some of your work on top of that, too.
>
>  Cheers,
> --stefan
>

You're right. I took a look at our old e-mails, and I found more details
about your work. It's definitely not affected by processor endianess, so you
don't need any check: it just works, because you'll produce the new opcodes
in memory, and consume them in memory as well.

Looking at your examples, I think that WPython wordcodes usage can be useful
only for the most simple ones. That's because superinstructions group
together several actions that need to be splitted again to simpler ones by a
tracing-JIT/compiler like your, if you want to keep it simple. You said that
you added about 400 specialized instructions last year with the usual
bytecodes, but wordcodes will require quite more (this can compromise
performance on CPU with small data caches).

So I think that it'll be better to finish your work, with all tests passed,
before thinking about adding something on top (that, for me, sounds like a
machine code JIT O:-)

Regards,
Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110831/f8ca4ce0/attachment.html>