Thanks for the info!That's all the questions I have, for now at least. Feel free to reply with any more tips if you think of any.
I read over your posts you linked, Carl. They were certainly informative and helpful, thanks. I'll keep thinking of ways to improve the performance of my test interpreter, but it's so simple, I don't think there's much more that can be done. The shared attribute maps described by that link don't really apply here.
In any case, I'm satisfied with the speed. It's still beaten by a BF to C translator combined with gcc -O2 though, that'd be a tough case to beat. =)
-Andrew
On Tue, Mar 29, 2011 at 5:33 AM, Armin Rigo
<arigo@tunes.org> wrote:
Hi Andrew,
On Mon, Mar 28, 2011 at 7:21 PM, Andrew Brown <
brownan@gmail.com> wrote:
> When the optimizer encounters a "pure" function, it must compare the objects
> "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?
One point of view on 'promote' is to mean "this variable was red, but
now turn it green (i.e. make it constant)". It has no effect on a
variable that is already green (= a constant).
We have no support for considering that a dict is immutable, so it
needs to be done with @purefunction. But to be effective,
@purefunction must receive constant arguments; so in one or two places
in the source code of PyPy you will find a construction like:
x = hint(x, promote=True) # turn x into a constant
some_pure_function(x) # call this pure function on x
Indeed, Carl Friedrich's blog series explains it nicely, but it should
also mention that when the hints described in the blog are applied not
to integer but to pointers, they apply only to the pointers
themselves, not on the fields of the objects they point to.
A bientôt,
Armin.