Re: [pypy-dev] Pypy custom interpreter JIT question

[Dan Roberts]

Hey sorry about that, I'm working full time now, and balancing life,
school and full time work is new for me...

http://paste.pocoo.org/show/366731/

Is it in its current state. I actually haven't tried it on "stock"
PyPy. I wrote an extra JIT optimization in the fold_intadd branch,
which gave me around 50% on mandelbrot, it may yield more for you, you
might try it out (I hope to have it merged once I get another set of
eyes on it, but like I said, life's been hectic, so I haven't gotten
the ball rolling on code review yet). My 99bottles.bf performance is
still abysmal. I'm going to go and implement caching of matching
brackets right now (lunch break woo!) and see what that does for my
performance.

Cheers,
Dan

On Wed, Apr 6, 2011 at 7:03 AM, Andrew Brown  wrote:
> Hmm, looks like the line numbers for the JIT trace output are mis-aligned,
> although it may just be my browser (Chrome beta). Looks fine in Firefox. Oh
> well.
> But anyways...
>
> On Wed, Apr 6, 2011 at 9:13 AM, Carl Friedrich Bolz  wrote:
>>
>> Thanks again, Andrew! FWIW, the first post is already on place four of
>> all PyPy blog posts in the ranking of page impressions.
>
> You're welcome! That's awesome to hear, I'm glad I could contribute.
> Also, Dan, if you wanted to post your version I'm curious to see your
> approach.
> -Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Dima Tisnek]

line numbers are totally broken in opera - looks like double-digit
number are split and spilt to the next line

safari looks better, but still as if line numbers are offset half a
line, so as if numbers point between the source code lines.

I used SyntaxHighlighter in blogs before, that works, highlights well,
gives you line numbers and doesn't interfere with selection. It's
presumably tested with all the browsers out there and it's a simple
drop-in.

d.

On 6 April 2011 07:12, Andrew Brown  wrote:
> No good, it still looks like this: http://i.imgur.com/nuLIf.png
> Chrome 12.0.712.0 dev on Ubuntu.
> -A
>
> On Wed, Apr 6, 2011 at 10:05 AM, Carl Friedrich Bolz  wrote:
>>
>> On 04/06/2011 04:03 PM, Andrew Brown wrote:
>>>
>>> Hmm, looks like the line numbers for the JIT trace output are
>>> mis-aligned, although it may just be my browser (Chrome beta). Looks
>>> fine in Firefox. Oh well.
>>
>> Can you re-load? I tried to fix it.
>>
>> Carl Friedrich
>
>
> ___
> pypy-dev@codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

No good, it still looks like this: http://i.imgur.com/nuLIf.png

Chrome 12.0.712.0 dev on Ubuntu.
-A

On Wed, Apr 6, 2011 at 10:05 AM, Carl Friedrich Bolz  wrote:

> On 04/06/2011 04:03 PM, Andrew Brown wrote:
>
>> Hmm, looks like the line numbers for the JIT trace output are
>> mis-aligned, although it may just be my browser (Chrome beta). Looks
>> fine in Firefox. Oh well.
>>
>
> Can you re-load? I tried to fix it.
>
> Carl Friedrich
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Carl Friedrich Bolz]

On 04/06/2011 04:03 PM, Andrew Brown wrote:
> Hmm, looks like the line numbers for the JIT trace output are
> mis-aligned, although it may just be my browser (Chrome beta). Looks
> fine in Firefox. Oh well.

Can you re-load? I tried to fix it.

Carl Friedrich
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Hmm, looks like the line numbers for the JIT trace output are mis-aligned,
although it may just be my browser (Chrome beta). Looks fine in Firefox. Oh
well.

But anyways...

On Wed, Apr 6, 2011 at 9:13 AM, Carl Friedrich Bolz  wrote:

> Thanks again, Andrew! FWIW, the first post is already on place four of
> all PyPy blog posts in the ranking of page impressions.
>

You're welcome! That's awesome to hear, I'm glad I could contribute.

Also, Dan, if you wanted to post your version I'm curious to see your
approach.

-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Carl Friedrich Bolz]

On 04/05/2011 03:54 PM, Armin Rigo wrote:
> Hi,
>
> On Tue, Apr 5, 2011 at 3:40 PM, Andrew Brown  wrote:
>> I corrected a typo and changed the wording in 2 places. They're not any huge
>> deals, but if you want to edit the post, see my changes here:
>> https://bitbucket.org/brownan/pypy-tutorial/changeset/8cfb3cd72515
>
> Thanks, applied.  I also removed your explicit e-mail address, and
> replaced it with a link to one of your previous posts on this mailing
> list, from where people can still get your e-mail if they want --- but
> at least it's partially filtered against spammers.

Second post is up too: http://bit.ly/fLjGHs

Thanks again, Andrew! FWIW, the first post is already on place four of 
all PyPy blog posts in the ranking of page impressions.

Carl Friedrich
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Hi,

On Tue, Apr 5, 2011 at 3:40 PM, Andrew Brown  wrote:
> I corrected a typo and changed the wording in 2 places. They're not any huge
> deals, but if you want to edit the post, see my changes here:
> https://bitbucket.org/brownan/pypy-tutorial/changeset/8cfb3cd72515

Thanks, applied.  I also removed your explicit e-mail address, and
replaced it with a link to one of your previous posts on this mailing
list, from where people can still get your e-mail if they want --- but
at least it's partially filtered against spammers.


A bientôt,

Armin.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

On Tue, Apr 5, 2011 at 8:54 AM, René Dudfield  wrote:

> hehe, I like how you managed to avoid the first letter of the second word
> of the language ;)
>

=) yeah, I had to think about that a bit.


Looked good, I just went ahead and posted the first part:
>
>
> http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html
>
> Will do the second part tomorrow. Thanks a lot for the tutorial, I think
> it's really great.
>

Thanks! It looks great up there.

I corrected a typo and changed the wording in 2 places. They're not any huge
deals, but if you want to edit the post, see my changes here:
https://bitbucket.org/brownan/pypy-tutorial/changeset/8cfb3cd72515

(summary: re-inventing -> re-implementing, toochain -> toolchain, and
clarified that the mandelbrot program is written in BF)

-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[René Dudfield]

Nice one!

hehe, I like how you managed to avoid the first letter of the second word of
the language ;)
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Carl Friedrich Bolz]

On 04/04/2011 10:28 PM, Andrew Brown wrote:
> On Mon, Apr 4, 2011 at 2:12 PM, Antonio Cuni  > wrote:
>
> sure, I think that for this example, using fd is fine.
>
> Btw, in case you want to do more with pypy, having a look to rlib
> might be a
> good idea, there is useful stuff there :)
>
> Definitely.
>
> In any case, I've made some changes, re-worded some things. Carl, I've
> addressed your suggestions, let me know what you think.
>
> I also re-worded a few things in the "Adding JIT" section to make it
> flow a bit better assuming it will be split up. It may still need some
> editing though.

Looked good, I just went ahead and posted the first part:

http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html

Will do the second part tomorrow. Thanks a lot for the tutorial, I think 
it's really great.

Carl Friedrich
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

On Mon, Apr 4, 2011 at 2:12 PM, Antonio Cuni  wrote:

> sure, I think that for this example, using fd is fine.
>
> Btw, in case you want to do more with pypy, having a look to rlib might be
> a
> good idea, there is useful stuff there :)
>
> Definitely.

In any case, I've made some changes, re-worded some things. Carl, I've
addressed your suggestions, let me know what you think.

I also re-worded a few things in the "Adding JIT" section to make it flow a
bit better assuming it will be split up. It may still need some editing
though.

-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Antonio Cuni]

On 04/04/11 19:46, Andrew Brown wrote:

> 1) do you know about the existence of rlib.streamio? It's is part of the
> "RPython standard library" and it allows you to read/write files in a 
> higher
> level way than file descriptors
> 
> No, I didn't. That's good to know. I don't think it's worth updating the
> examples though, so unless you disagree, I'll just add a note about this
> module's existence.

sure, I think that for this example, using fd is fine.

Btw, in case you want to do more with pypy, having a look to rlib might be a
good idea, there is useful stuff there :)

ciao,
Anto
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

On Mon, Apr 4, 2011 at 12:34 PM, Antonio Cuni  wrote:

> 1) do you know about the existence of rlib.streamio? It's is part of the
> "RPython standard library" and it allows you to read/write files in a
> higher
> level way than file descriptors
>
> No, I didn't. That's good to know. I don't think it's worth updating the
examples though, so unless you disagree, I'll just add a note about this
module's existence.


> 2) Maybe the tutorial is a bit too long to fit in just one post; what about
> splitting it into two parts? (e.g., one until "Adding JIT" and one after).
>
> Yes, it is quite long.

Carl, feel free to break it up as necessary when you post it. Breaking it up
at the "Adding JIT" section seems ideal, since both parts are useful on
their own.

-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Thanks for the feedback. I'll clarify those parts, and I have a few
touch-ups of my own. Also, I think I forgot to add my name =)

I'm fine with you posting it as you described. An into line like that was
just what I had in mind. I'd wait until tomorrow though to see if any other
feedback surfaces.

On Mon, Apr 4, 2011 at 12:17 PM, Carl Friedrich Bolz  wrote:

> On 04/04/2011 05:43 PM, Andrew Brown wrote:
>
>> On Mon, Apr 4, 2011 at 11:22 AM, Carl Friedrich Bolz > > wrote:
>>
>>
>>Looks very nice! Would you be up to making a guest post out of this on
>>the PyPy blog?
>>
>> Sure! What needs to be done to turn it into a blog post and get it
>> posted? I assume there are format considerations, but I'm also open to
>> any content suggestions and feedback before it "goes live".
>>
>
> I looked again, added two places that could use small fixes. And I updated
> two links, see my merge request. Apart from that, the blog post would not
> need many changes. It would need an introductionary line like:
>
> "This is a guest post by Andrew Brown. It's a tutorial for how to write an
> interpreter with PyPy, generating a JIT. It is suitable for beginners and
> assumes very little knowledge of PyPy."
>
> Then we should link to the repo, and replace all file links with links to
> bitbucket. I can do all that, and post it (tomorrow), if you are fine with
> that.
>
> Carl Friedrich
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Antonio Cuni]

On 04/04/11 17:43, Andrew Brown wrote:

> Sure! What needs to be done to turn it into a blog post and get it posted? I
> assume there are format considerations, but I'm also open to any content
> suggestions and feedback before it "goes live".

Hello Andrew,
thanks for the tutorial, it's really well written and easy to read.

Two notes:

1) do you know about the existence of rlib.streamio? It's is part of the
"RPython standard library" and it allows you to read/write files in a higher
level way than file descriptors

2) Maybe the tutorial is a bit too long to fit in just one post; what about
splitting it into two parts? (e.g., one until "Adding JIT" and one after).

ciao,
Anto
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Carl Friedrich Bolz]

On 04/04/2011 05:43 PM, Andrew Brown wrote:
> On Mon, Apr 4, 2011 at 11:22 AM, Carl Friedrich Bolz  > wrote:
>
>
> Looks very nice! Would you be up to making a guest post out of this on
> the PyPy blog?
>
> Sure! What needs to be done to turn it into a blog post and get it
> posted? I assume there are format considerations, but I'm also open to
> any content suggestions and feedback before it "goes live".

I looked again, added two places that could use small fixes. And I 
updated two links, see my merge request. Apart from that, the blog post 
would not need many changes. It would need an introductionary line like:

"This is a guest post by Andrew Brown. It's a tutorial for how to write 
an interpreter with PyPy, generating a JIT. It is suitable for beginners 
and assumes very little knowledge of PyPy."

Then we should link to the repo, and replace all file links with links 
to bitbucket. I can do all that, and post it (tomorrow), if you are fine 
with that.

Carl Friedrich
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

On Mon, Apr 4, 2011 at 11:22 AM, Carl Friedrich Bolz  wrote:

>
> Looks very nice! Would you be up to making a guest post out of this on
> the PyPy blog?
>
> Sure! What needs to be done to turn it into a blog post and get it posted?
I assume there are format considerations, but I'm also open to any content
suggestions and feedback before it "goes live".

-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Hi Andrew,

On Mon, Apr 4, 2011 at 4:12 PM, Andrew Brown  wrote:
> Submitted for everyone's approval, I've written a draft of a pypy tutorial
> going over everything I learned in writing this example interpreter.
> https://bitbucket.org/brownan/pypy-tutorial/src

Excellent and, as far as I can tell, very clear too!


A bientôt,

Armin.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Carl Friedrich Bolz]

On 04/04/2011 04:12 PM, Andrew Brown wrote:
> Submitted for everyone's approval, I've written a draft of a pypy
> tutorial going over everything I learned in writing this example
> interpreter.
>
> https://bitbucket.org/brownan/pypy-tutorial/src
>
> See the main document at tutorial.rst
>
> I'd
> love some feedback on it. I've made an effort to keep things accurate
> yet simple, but if there are any inaccuracies, let me know. Or fork the
> repo and make the correction yourself =)

Looks very nice! Would you be up to making a guest post out of this on 
the PyPy blog?

Carl Friedrich
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Submitted for everyone's approval, I've written a draft of a pypy tutorial
going over everything I learned in writing this example interpreter.

https://bitbucket.org/brownan/pypy-tutorial/src

See the main document at tutorial.rst

I'd
love some feedback on it. I've made an effort to keep things accurate yet
simple, but if there are any inaccuracies, let me know. Or fork the repo and
make the correction yourself =)

-Andrew

On Thu, Mar 31, 2011 at 6:29 PM, Alex Gaynor  wrote:

>
>
> On Thu, Mar 31, 2011 at 6:00 PM, Antonio Cuni  wrote:
>
>> On 31/03/11 22:05, Andrew Brown wrote:
>>
>> > python double-interpreted: > 78m (did not finish)
>> > pypy-c (with jit) double-interpreted: 41m 34.528s
>>
>> this is interesting. We are beating cpython by more than 2x even in a
>> "worst
>> case" scenario, because interpreters in theory are not a very good target
>> for
>> tracing JITs.
>> However, it's not the first time that we experience this, so it might be
>> that
>> this interpreter/tracing JIT thing is just a legend :-)
>>
>>
> Well the issue with tracing an interpreter is the large number of paths, a
> brainfuck interpreter has relatively few paths compared to something like a
> Python VM.
>
>
>
>
>> > translated interpreter no jit: 45s
>> > translated interpreter jit: 7.5s
>> > translated direct to C, gcc -O0
>> >   translate: 0.2s
>> >   compile: 0.4s
>> >   run: 18.5s
>> > translated direct to C, gcc -O1
>> >   translate: 0.2s
>> >   compile: 0.85s
>> >   run: 1.28s
>> > translated direct to C, gcc -O2
>> >   translate: 0.2s
>> >   compile: 2.0s
>> >   run: 1.34s
>>
>> these are cool as well. We are 3x faster than gcc -O0 and ~3x slower than
>> -O1
>> and -O2.  Pretty good, I'd say :-)
>>
>> ciao,
>> anto
>> ___
>> pypy-dev@codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>
> 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
>
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Alex Gaynor]

On Thu, Mar 31, 2011 at 6:00 PM, Antonio Cuni  wrote:

> On 31/03/11 22:05, Andrew Brown wrote:
>
> > python double-interpreted: > 78m (did not finish)
> > pypy-c (with jit) double-interpreted: 41m 34.528s
>
> this is interesting. We are beating cpython by more than 2x even in a
> "worst
> case" scenario, because interpreters in theory are not a very good target
> for
> tracing JITs.
> However, it's not the first time that we experience this, so it might be
> that
> this interpreter/tracing JIT thing is just a legend :-)
>
>
Well the issue with tracing an interpreter is the large number of paths, a
brainfuck interpreter has relatively few paths compared to something like a
Python VM.




> > translated interpreter no jit: 45s
> > translated interpreter jit: 7.5s
> > translated direct to C, gcc -O0
> >   translate: 0.2s
> >   compile: 0.4s
> >   run: 18.5s
> > translated direct to C, gcc -O1
> >   translate: 0.2s
> >   compile: 0.85s
> >   run: 1.28s
> > translated direct to C, gcc -O2
> >   translate: 0.2s
> >   compile: 2.0s
> >   run: 1.34s
>
> these are cool as well. We are 3x faster than gcc -O0 and ~3x slower than
> -O1
> and -O2.  Pretty good, I'd say :-)
>
> ciao,
> anto
> ___
> pypy-dev@codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

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
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Antonio Cuni]

On 31/03/11 22:05, Andrew Brown wrote:

> python double-interpreted: > 78m (did not finish)
> pypy-c (with jit) double-interpreted: 41m 34.528s

this is interesting. We are beating cpython by more than 2x even in a "worst
case" scenario, because interpreters in theory are not a very good target for
tracing JITs.
However, it's not the first time that we experience this, so it might be that
this interpreter/tracing JIT thing is just a legend :-)

> translated interpreter no jit: 45s
> translated interpreter jit: 7.5s
> translated direct to C, gcc -O0
>   translate: 0.2s
>   compile: 0.4s
>   run: 18.5s
> translated direct to C, gcc -O1
>   translate: 0.2s
>   compile: 0.85s
>   run: 1.28s
> translated direct to C, gcc -O2
>   translate: 0.2s
>   compile: 2.0s
>   run: 1.34s

these are cool as well. We are 3x faster than gcc -O0 and ~3x slower than -O1
and -O2.  Pretty good, I'd say :-)

ciao,
anto
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

On Thu, Mar 31, 2011 at 2:09 PM, Dima Tisnek  wrote:

> What if bf code was really really large?
>

I've only been testing with the examples at hand included in my repo. The
mandelbrot and towers of hanoi examples are pretty big though. If you can
find some larger examples, I'd like to try them.

I think it can be a great example. It's very educational ;-)


> It could go into official docs/howto too.
>

Awesome! I'm working on writing up everything, it's turning out to be pretty
long. I'm assuming no prior PyPy knowledge in the readers though =)

Here are a few numbers from tests I just did.

python double-interpreted: > 78m (did not finish)
pypy-c (with jit) double-interpreted: 41m 34.528s
translated interpreter no jit: 45s
translated interpreter jit: 7.5s
 translated direct to C, gcc -O0
  translate: 0.2s
  compile: 0.4s
  run: 18.5s
translated direct to C, gcc -O1
  translate: 0.2s
  compile: 0.85s
  run: 1.28s
translated direct to C, gcc -O2
  translate: 0.2s
  compile: 2.0s
  run: 1.34s

These were all running the mandelbrot program.

-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Dima Tisnek]

On 31 March 2011 05:33, Antonio Cuni  wrote:
> On 31/03/11 14:28, Andrew Brown wrote:
>> 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. =)

What if bf code was really really large?

bf to c then gcc could take a hit as it might thrash cpu cache, as
single pass gcc doesn't know what a given program would actually do at
runtime.

jit'd rpy would only have 1 hotspot, always in cache, and might be a
little smarter too.

I suppose it's hard to beat 2-pass (profile driven optimized) compiled c though.

>
> what happens if you combine the BF to C with gcc -O0 or -O1?
>
> Anyway, I think that if you feel like writing a post explaining your
> experience with using pypy and its jit for writing an interpreter, we could
> publish it on our blog.  I suppose it would be useful/interesting for other
> people as well.
>
> What do the others think?

I think it can be a great example. It's very educational ;-)

It could go into official docs/howto too.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Here's three emails that accidentally didn't get sent to the list.

On Thu, Mar 31, 2011 at 10:41 AM, Dan Roberts  wrote:

> Hi Andrew,
> Did you ever try your interpreter with the 99 bottles program? I got my
> interpreter down faster than the beef interpreter ~4s vs ~15s on mandelbrot,
> however even with that speed, both 'bf' and 'beef' trounced my interpreter
> by an absurd amount. It seems like it probably was a problem with my code
> base, when I first saw you were working on this I meant to ask you to try
> 99bottles.bf and see if you had similar problems. I haven't had a chance
> to examine where the problem is coming from though.
>
> Cheers,
> Dan
>

On Thu, Mar 31, 2011 at 11:02 AM, Andrew Brown  wrote:

> Hi Dan,
> Did you mean to send this to the list as well? I only ask because it's easy
> to hit "Reply" instead of "Reply All".
>
> Regardless, I have a 99 bottles program, in the comments it says it's
> written by Andrew Paczkowski. I haven't mentioned it just because it runs
> absurdly fast: 0.02 seconds or so (compared with 0.2s for running the py
> code on cpython), so I didn't consider it a good test. I wanted something
> that took a bit longer.
>
> I just searched for another and found one by Raphael Bois, but that runs in
> 0.04 seconds.
>
> Perhaps you're using a different version of this program that's less
> efficient and runs faster? (or maybe this really is just that fast?)
>
> Also, the mandelbrot program that I included in my repo takes 8.4 seconds
> to run on my computer. Not quite the 4 second time you're getting (have you
> published your interpreter anywhere? I'd like to look at it) I have a
> feeling I've taken this interpreter as far as it will go without doing any
> more intelligent inspection of the bf code directly.
>
> -Andrew
>

On Thu, Mar 31, 2011 at 11:20 AM, Dan Roberts  wrote:

> Hey,
> Yeah, that's the second or third time I didn't reply to all lately :-/
> And my interpreter is on paste.pocoo.org somewhere, I can paste it again
> when I go home today. I suspect there's something wrong with it though,
> considering you're getting proper performance on 99bottles, it takes about 3
> minutes here! (On the same system where it wins on mandelbrot by >66%
> against 'beef' or bf whichever one is faster) One immediately obvious
> difference was your use of the bracket map, which I think is an awesome
> idea. I may adopt it, currently I calculate how far backwards/forwards to
> travel at "runtime" instead of preprocessing it. I made it pure so that it
> would be constant folded by the JIT, but I suppose the 1000 iterations
> before the JIT kicks in (per loop) could explain a large performance
> difference. I could probably combine both techniques and cache the results
> at runtime, by the second run, it'll be a dict lookup, so it'll be jitted
> essentially the same, and I won't have to think about parsing to find
> matching braces :-)
>
> If you can think of a good way to bring this discussion back on the mailing
> list that'd be fine.
>
> Cheers,
> Dan
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Timothy Baldridge]

> Sure I'll write up a post. This was a lot of fun, and I think it's a great
> way to teach people how pypy works.

I'd love to read a post on this. Perhaps I'll get a few pointers that
I can use in my Clojure-pypy port.

Timothy
-- 
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Compiling with -O0 is really quick, but the runtime is fairly slow. I
haven't tried with -O1. -O2 takes a few seconds to compile, but that plus
runtime is still faster than the pypy version with jit, but not by too much
(I'm recalling the tests I did with the mandelbrot program specifically). I
can get some actual numbers later today.

Sure I'll write up a post. This was a lot of fun, and I think it's a great
way to teach people how pypy works.

-Andrew

On Thu, Mar 31, 2011 at 8:33 AM, Antonio Cuni  wrote:

> On 31/03/11 14:28, Andrew Brown wrote:
> > 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.
> =)
>
> what happens if you combine the BF to C with gcc -O0 or -O1?
>
> Anyway, I think that if you feel like writing a post explaining your
> experience with using pypy and its jit for writing an interpreter, we could
> publish it on our blog.  I suppose it would be useful/interesting for other
> people as well.
>
> What do the others think?
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Laura Creighton]

In a message of Thu, 31 Mar 2011 14:33:40 +0200, Antonio Cuni writes:
>On 31/03/11 14:28, Andrew Brown wrote:
>> 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
>. =)
>
>what happens if you combine the BF to C with gcc -O0 or -O1?
>
>Anyway, I think that if you feel like writing a post explaining your
>experience with using pypy and its jit for writing an interpreter, we cou
>ld
>publish it on our blog.  I suppose it would be useful/interesting for oth
>er
>people as well.
>
>What do the others think?

I'd look forward to reading it.

Laura

___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Antonio Cuni]

On 31/03/11 14:28, Andrew Brown wrote:
> 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. =)

what happens if you combine the BF to C with gcc -O0 or -O1?

Anyway, I think that if you feel like writing a post explaining your
experience with using pypy and its jit for writing an interpreter, we could
publish it on our blog.  I suppose it would be useful/interesting for other
people as well.

What do the others think?
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

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  wrote:

> Hi Andrew,
>
> On Mon, Mar 28, 2011 at 7:21 PM, Andrew Brown  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.
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Hi Andrew,

On Mon, Mar 28, 2011 at 7:21 PM, Andrew Brown  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.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Carl Friedrich Bolz]

On 03/28/2011 07:21 PM, Andrew Brown wrote:
> 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?

Not really, no :-(

> 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:
> https://bitbucket.org/brownan/bf-interpreter/src/d3394345272e/targetbf.py
>
> 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?

Just the object's identity.

> 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?
>

If you are interested, this blog series explains the usage of hints:

http://bit.ly/bundles/cfbolz/1

The logs there are a bit niceified though.

Carl Friedrich
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

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:
https://bitbucket.org/brownan/bf-interpreter/src/d3394345272e/targetbf.py

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  wrote:

> Hi Andrew,
>
> On Fri, Mar 25, 2011 at 5:47 PM, Andrew Brown  wrote:
> > Thanks, it does indeed work now!
>
> The next step is to have a look at the traces produced (run with
> 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.
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Hi Andrew,

On Fri, Mar 25, 2011 at 5:47 PM, Andrew Brown  wrote:
> Thanks, it does indeed work now!

The next step is to have a look at the traces produced (run with
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.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Thanks, it does indeed work now!
-Andrew

On Thu, Mar 24, 2011 at 12:56 PM, Armin Rigo  wrote:

> Re-hi,
>
> On Thu, Mar 24, 2011 at 5:11 PM, Armin Rigo  wrote:
> > Working on it, by cleaning up optimizeopt/heap.py...
>
> Done, at least as far as fixing the bug is concerned.  Now your
> original version (with can_enter_jit removed) works.
>
> Armin
>
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Re-hi,

On Thu, Mar 24, 2011 at 5:11 PM, Armin Rigo  wrote:
> Working on it, by cleaning up optimizeopt/heap.py...

Done, at least as far as fixing the bug is concerned.  Now your
original version (with can_enter_jit removed) works.

Armin
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Hi Andrew,

On Wed, Mar 23, 2011 at 8:27 PM, Andrew Brown  wrote:
> However, the version that didn't work before still does not run
> correctly. It seems like I'm still left with the same problem as before.

Ah.  Looking more closely, it turns out to be a bug in the
optimization step of the JIT which just never showed up so far :-/

Working on it, by cleaning up optimizeopt/heap.py...


Armin
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

On Tue, Mar 22, 2011 at 5:54 PM, Armin Rigo  wrote:

> can_enter_jit() is not correct.  For it to work, it must be called
> just before jit_merge_point().  It's wrong that there are two
> intermediate instructions here: "pc+=1" and the "pc < len(program)"
> condition.
>

Okay, I think I understand. I'm still learning how all this stuff works.
Regardless...

>
> As a first attempt, you should just not call can_enter_jit() at all.
> Nowadays, if can_enter_jit is never called, it's done automatically
> for you;


I did not know this. Good to know!

I've removed the can_enter_jit() call from the two versions of my
interpreter. However, the version that didn't work before still does not run
correctly. It seems like I'm still left with the same problem as before.

This works (version without Tape class and with can_enter_jit call removed)
https://bitbucket.org/brownan/bf-interpreter/src/6c6c80397554/targetbf.py
Incidentally, I think it may run slightly slower now, but I'm not sure.

This version still does not (version *with* Tape class, and with
can_enter_jit removed)
https://bitbucket.org/brownan/bf-interpreter/src/1d16c3eed7e2/targetbf.py

Any other ideas? I'm still at a loss. Thanks for taking a look!
-Andrew
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: [pypy-dev] Pypy custom interpreter JIT question

[Armin Rigo]

Hi Andrew,

On Tue, Mar 22, 2011 at 8:44 PM, Andrew Brown  wrote:
> https://bitbucket.org/brownan/bf-interpreter/src/c4679b354313/targetbf.py

can_enter_jit() is not correct.  For it to work, it must be called
just before jit_merge_point().  It's wrong that there are two
intermediate instructions here: "pc+=1" and the "pc < len(program)"
condition.

As a first attempt, you should just not call can_enter_jit() at all.
Nowadays, if can_enter_jit is never called, it's done automatically
for you; moreover, a misplaced can_enter_jit can give nonsensical
results, as opposed to many other hints, which cannot give a result
worst than terribly bad performance (like the greens/reds variable
separation --- which seems correct in your example).


A bientôt,

Armin.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

[pypy-dev] Pypy custom interpreter JIT question

[Andrew Brown]

Hello PyPy team,

So I became interested in the translation toolchain plus JIT compiler
generator, and in attempt to learn more about it, I set out to write a very
simple interpreter for the language BF (brainf***). Simple enough, 8
opcodes, each with no arguments, and most have a one line implementation.
Also plenty of examples out there to run, like a mandelbrot generator =)

So I wrote up an interpreter for it in RPython. This worked great until I
tried to enable the JIT option, at which point it would produce incorrect
results. Strange, I thought I may have been using the hints incorrectly, I
couldn't find too many details on exactly what the red and green vars should
be.

Here's the strange part though: I finally fixed it by changing an
implementation detail that shouldn't have changed semantics at all.

My implementation creates an instance of a Tape object which has two
attributes: a list of integers representing the state of the machine, and a
single integer identifying the current active cell on the tape.

The implementation of each opcode was a method of this class, and the state
of the program (what I passed as the "red" variable) was the instance of
this class.

After I manually factored the functionality of the class directly into the
main dispatch loop and got rid of the class entirely, the JIT compiler
started producing correct results.

Can anyone help me figure out why my first attempt didn't work? Do red
variables that are in class instances need to be handled different somehow?

Here's the initial version that runs incorrectly when translated with JIT:
https://bitbucket.org/brownan/bf-interpreter/src/c4679b354313/targetbf.py
Here's the modified version that seems to work just fine:
https://bitbucket.org/brownan/bf-interpreter/src/8095853278e9/targetbf.py

In particular, note the elimination of the Tape object in the second
version, and the differences in the mainloop function as well as the
differences in the "red" variables.

I've also included a few example BF programs if someone wants to try it out.
The hanoi example crashes almost immediately with the first version
translated with JIT.

By the way, I've been translating it with the latest version of PyPy off of
bitbucket. (latest as of a few weeks ago, that is)

Thanks and great work on this project!
-Andrew Brown
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev