On May 9, 1:25 pm, John Nagle <[EMAIL PROTECTED]> wrote: > Marc 'BlackJack' Rintsch wrote: > > I don't see how this type inference for static types will work unless some > > of the dynamism of the language will get restricted. But is this really > > necessary? Isn't a JIT compiler and maybe type hinting good enough? > > Not necessarily. One of the more powerful optimizations is to optimize > reference count updates. Often, you can hoist reference count updates > out of loops, which is a big win. But to do that, you need to be sure > that the code executed by the loop won't change unexpectedly.
The advantage of having a JIT is just that it can record data at runtime and respond flexible to them. It doesn't run into global static analysis problems mentioned by Paul. A "semi-dynamical" compromise would mean to use a profile of samples of runtime data and assert that they reflect typical" behaviour. Then the system needs an ability to fall back to usual bytecode interpretation. Psyco does that by analyzing the next opcode and a very clever dispatch mechanism. A more code oriented, profile driven approach would factor source into natively compilable parts and those that have to be bytecode interpreted. I wonder whether bridges to Pyrex, Boost.Python or the celerid bridge to D could be used and what the performance penalties are for all the argument/return value wrapping and unwrapping. Unfortunately ShedSkin lacks CPython integration. We talked about this here recently. Kay -- http://mail.python.org/mailman/listinfo/python-list
