Hi, On Wed, Feb 2, 2011 at 4:48 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > As of now there is no such guide. However, the rule of thumb is simple > is better than complex.
To some extend that is true; however, note that the second rule is "but even on messily complicated code the JIT can do something" :-) For example, "translate.py" was not written with the JIT in mind at all, but turns out to be twice as fast on PyPy. To get a better summary, I think that we can say that, to some extent, there is little point in spending ages tweaking your Python code to make it more JIT-friendly. If there is any Python code that would get seriously faster by some trivial tweaking, then it's somehow a bug, and we need to fix it. Of course, if you use introspection of the stack frames or even pdb (the Python debugger) all over the place, you need to expect the code to be hard to optimize for us. But I guess that it should somehow be clear. For the rest, any decision that can be resolved "locally" can nicely be optimized by the JIT, whatever the answer is (for example, "is this '+' going to just add integers, or does it invoke some __add__() method?"). A bientôt, Armin. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
