Re: [pypy-dev] RinohType and PyPy2
Hi Brecht.
I must say I've been trying to understand what's going on and I'm failing so far. Thanks for a valuable benchmark! And yes, we're working on improving the warmup time (ETA unknown though)
On Sun, Mar 2, 2014 at 12:11 PM, Brecht Machiels brecht@mos6581.org wrote:
Thanks Maciej,
sys._getframe was introduced by "magicsuper", which I used to avoid refactoring all super() calls. I've done that now and there shouldn't be any more sys._getframe calls. You can pull in this commit from the pypy2 branch.
Unfortunately, this didn't improve performance much. PyPy now takes 26 seconds. Any other ideas?
Best regards, Brecht
---- On Sun, 02 Mar 2014 08:19:35 +0100 Maciej Fijalkowski wrote ----
the first obvious thing that jumps at me is your casual use of sys._getframe - the JIT aborts in this case and proceeds to the interpreter (so you pay the price for JITting, while you also pay the prace for not having compiled assembler). That probably does not explain everything, but please don't use sys._getframe in production code if you want the JIT to be fast.
On Sun, Mar 2, 2014 at 12:34 AM, Brecht Machiels
wrote:
Hello,
I've managed to backport RinohType to Python 2 (took me only a couple of hours thankfully).
Results on my Celeron T3000 (Arch Linux x86_64): CPython 3.3.4 14 s PyPy3 2.1.0-beta1 61 s CPython 2.7.6 15 s PyPy 2.2.1 35 s
If you want to give it a try (no external dependencies):
git clone --branch pypy2 https://github.com/brechtm/rinohtype.git cd rinohtype/examples/rfic2009 rm -rf template.ptc; PYTHONPATH=../.. pypy template.py
While PyPy2 performs better than PyPy3, it's still much slower than CPython. Is RinohType hitting a weak spot in PyPy? Any hints on what I can do to improve performance?
Best regards, Brecht
pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Hello Maciej and Armin,
Glad you think this is a valuable benchmark, since I provided it mostly for selfish reasons ;)
I've done a quick test similar to Armin's, rendering the original 4-page document over and over again. While I can see the speed improving, it still doesn't reach CPython's performance.
I haven't found the time yet to try with a longer document. I'll render a book from project Gutenberg soon and report back here. Let me know if there's anything else I can do.
Bengt Richter raised an interesting question (but his message didn't seem to make it to the list):
Is there any way that jit results could be cached to some degree, in one or more files, to give the next execution of a program a warmer start?
I remember seeing a similar question before. IIRC one suggestion was to spawn a daemon process. I suppose that could work for RinohType, but I'm also interested to hear if it would be possible to have PyPy save the JIT state to a file on termination.
Cheers, Brecht
---- On Sun, 02 Mar 2014 22:15:28 +0100 Maciej Fijalkowskifijall@gmail.com wrote ----
I must say I've been trying to understand what's going on and I'm failing so far. Thanks for a valuable benchmark! And yes, we're working on improving the warmup time (ETA unknown though)
---- On Sun, 02 Mar 2014 17:01:32 +0100 Armin Rigoarigo@tunes.org wrote ----
On 1 March 2014 23:34, Brecht Machiels brecht@mos6581.org wrote:
While PyPy2 performs better than PyPy3, it's still much slower than CPython. Is RinohType hitting a weak spot in PyPy? Any hints on what I can do to improve performance?
It's not really helpful, but the warm-up time is the first issue here. If I edit template.py to run it e.g. 10 times instead of only once, the speed grows quickly by a factor of 4. It means your code, for some reason, exhibits slow warm-ups (not the worst we've seen, but I agree it's a lot). It would be interesting to know if you have a similar speed-up when processing a single 10-times-larger document instead of 10 times the same small document :-)
A bientôt,
Armin.
On Mar 11, 2014, at 16:49, Brecht Machiels brecht@mos6581.org wrote:
Is there any way that jit results could be cached to some degree, in one or more files, to give the next execution of a program a warmer start?
I remember seeing a similar question before. IIRC one suggestion was to spawn a daemon process. I suppose that could work for RinohType, but I'm also interested to hear if it would be possible to have PyPy save the JIT state to a file on termination.
There's a FAQ entry for that! :)
http://pypy.readthedocs.org/en/improve-docs/faq.html#couldn-t-the-jit-dump-a...
participants (3)
-
Brecht Machiels -
Maciej Fijalkowski -
Taavi Burns