On Thu, Feb 3, 2011 at 5:03 PM, Armin Rigo <ar...@tunes.org> wrote: > 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?"). >
I disagree a bit. The example would be newstylization of classes. This is making your code more JIT friendly and it's not trivial to optimize this from the JIT standpoint. > > A bientôt, > > Armin. > _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
