I tried that logging option once, but I didn't know how to read the logs. They're not exactly self explanatory. Is there a resource somewhere that explains how to read those logs?
Regardless, I've implemented your suggestion and moved reads from that dictionary to a function decorated with @purefunction. Indeed, performance is greatly improved! Thanks!
Current version:
A few questions:
When the optimizer encounters a "pure" function, it must compare the objects passed in to previous invocations... does it consider the contents of container or other mutatible objects? or just the object identity, to be part of the function's input?
It looks like, from logs of my new version, it's not reading from the dictionary at all during the trace, so I would guess it's not considering the actual contents of the dictionary as part of the function's input. This isn't surprising, but I just want to know for sure.
Second, I noticed in jit.py the function hint() which has a parameter: "promote - promote the argument from a variable into a constant". Could this be an appropriate alternate to the @purefunction solution? Or, I'm guessing, does it just mean the name bracket_map won't change bindings, but does not impose a restriction on mutating the dictionary?
-Andrew
On Fri, Mar 25, 2011 at 2:18 PM, Armin Rigo
<arigo@tunes.org> wrote:
Hi Andrew,
On Fri, Mar 25, 2011 at 5:47 PM, Andrew Brown <
brownan@gmail.com> wrote:
> Thanks, it does indeed work now!
PYPYLOG=jit-log-opt:logfile), and spot the obvious missing
optimizations. The biggest issue seems to be the fact that the
dictionary 'bracket_map' is green, but it is not enough to ensure that
it is a constant dict (it could be mutated behind the JIT's back); so
in the end, every trace contains reads from it. You could fix it by
moving the line
newpc = bracket_map[pc]
to a new function to which you apply the decorator @pypy.rlib.jit.pure_function.
A bientôt,
Armin.