<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 25, 2010, at 4:29 PM, Miquel Torres wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi all!<br><br>I have implemented a small new feature for the speed center. In the Overview, you are now able to select to which results you wish to compare the performance of the selected interpreter. That allows a couple of interesting investigations to be made (bear with me if I say obvious things):<br>
<br>1 - <a href="http://speed.pypy.org/overview/?interpreter=3">http://speed.pypy.org/overview/?interpreter=3</a>)<br>We already knew that there are 5 benchmarks where pypy-c without the jit is more than twice times slower than cpython: slowspitfire,
twisted_iteration, twisted_tcp, html5lib and worst of all spambayes.<br><br>2 - <a href="http://speed.pypy.org/overview/">http://speed.pypy.org/overview/</a><br>The jit makes up for some of them, only twisted_tcp, slowspitfire and spambayes remain as cases where cpython is much faster.<br>
<br>3 - <a href="http://speed.pypy.org/overview/?baseline=4">http://speed.pypy.org/overview/?baseline=4</a><br>We can now compare pypy-c-jit with cpython with psyco acceleration. The first thing that stands out, is that pypy is much slower... exactly in the same cases where pypy-c without the jit is slower than cpython (no surprise). The second one, is that apart from those 5 cases where the jit is held back by bad pypy-c baseline performance, pypy-c-jit is already much better than psyco, about twice as fast!<br></blockquote><div><br></div>Pretty cool, but is python with psyco using psyco.full or just jitting some parts? maybe there is a lot of room for manually tunning psyco (but there is no way to do this for pypy afaik).<br><div><br></div><br><blockquote type="cite">4 - <a href="http://speed.pypy.org/overview/?baseline=3">http://speed.pypy.org/overview/?baseline=3</a><br>Another new comparison is pypy-c-jit to pypy-c (revision 72012). Here we can confirm that the jit accelerates *everything* that we currenly measure, and most by a very good factor. The 3 slow benchmarks from comparison 2 are here last, the are accelerated the least by the jit.<br>
<br>So to me the conclusion is that the jit has good enough performance for a first version, and that only poor pypy-c performance in some cases is holding the pypy project from becoming a better option than cpython. Wouldn't it be a good aim to make it a priority of the next (1.3?) release to improve on that? ;-)<br>
<br>Apart from it making pypy more "ready", there is a problem if that is not addressed while further jit development continues. An application is only so fast as its slowest part, so even if the jit accelerates some cases 100-fold, it won't help many applications.<br>
<br>I plan to add a new view with graphs that will show exactly what the problem is.<br><br>Cheers!<br>Miquel<br><br><br>PD: you can also for example compare pypy-c-jit to pypy-c-jit 72012 and see what improvements there have been since then<br>
_______________________________________________<br><a href="mailto:pypy-dev@codespeak.net">pypy-dev@codespeak.net</a><br>http://codespeak.net/mailman/listinfo/pypy-dev</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>--</div><div>Leonardo Santagada</div><div>santagada at <a href="http://gmail.com">gmail.com</a></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>