On Wed, Feb 2, 2011 at 9:07 AM, Jacob Hallén <jacob@openend.se> wrote:

onsdag 02 februari 2011 03.09.09 skrev Łukasz Ligowski:

...

I'd like to ask are there any rules of thumb to write code that PyPy JIT can easily optimize? Or maybe which constructs are hardly optimizable by JIT so it's better to avoid them?

If you want absolutely best performance, write your code in a simple, straight forward way, trying to keep your most used loops free of branches.

if a: for x in range(big number): calculate something else: for x in range(big number): calculate something else

generates better code than

for x in range(big number): if a: calculate something else: caculate something else

In the second case, there will be a guard inside the loop that has to be evaluated every time through.

Jacob Hallén _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev

If you happen to be doing numerical calculations using the array module instead of lists will help. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero

On Wed, Feb 2, 2011 at 4:07 PM, Jacob Hallén <jacob@openend.se> wrote:

onsdag 02 februari 2011 03.09.09 skrev  Łukasz Ligowski:

...

I'd like to ask are there any rules of thumb to write code that PyPy JIT can easily optimize? Or maybe which constructs are hardly optimizable by JIT so it's better to avoid them?

If you want absolutely best performance, write your code in a simple, straight forward way, trying to keep your most used loops free of branches.

if a:    for x in range(big number):        calculate something else:    for x in range(big number):        calculate something else

generates better code than

for x in range(big number):    if a:        calculate something    else:        caculate something else

In the second case, there will be a guard inside the loop that has to be evaluated every time through.

You have outdated information Jacob, not any more :)

Jacob Hallén _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev

Hi, On Wed, Feb 2, 2011 at 4:48 PM, Maciej Fijalkowski <fijall@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.

Hi, On Fri, Feb 4, 2011 at 7:44 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:

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.

"We know there is an issue there but we don't want to invest the large efforts to improve it because it's really the Python program's fault for using a mixture of deprecated and modern features"... Sure, you have a point. I was taking a rather theoretical point of view in my previous e-mail. A bientôt, Armin.