<div dir="ltr"><div class="gmail_extra">2013/5/30 Nathan Hurst <span dir="ltr"><<a href="mailto:njh@njhurst.com" target="_blank">njh@njhurst.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Does it still make sense to add programs like this to our benchmarks?<br>
> So far, our benchmarks are "real-life" examples.  The benchmarks like<br>
> above are completely missing the point of PyPy, as they don't stress<br>
> at all the Python interpreter part.  There are also other cases where<br>
> PyPy's performance is very bad, like cpyext on an extension module<br>
> with lots of small C API calls.  I believe that it would still make<br>
> sense to list such cases in the official benchmark, and have the<br>
> descriptions of the benchmarks explain what's wrong with them.<br>
<br>
</div>I agree that you should include them, I disagree that they are<br>
'wrong'.  They measure the overhead of a C call.  Why should a C call<br>
be slower in pypy than cpython?  Presumably it could be compiled down<br>
to the appropriate instructions and then out-perform cpy.<br></blockquote><div><br></div><div style>The C API here is the one of the CPython interpreter (PyLong_FromLong &co)</div><div style>To support it PyPy has to emulate many aspects, specially the fact that pypy</div>
<div style>objects are movable memory, and a PyObject* pointer is not supposed to change.</div></div><div class="gmail_extra"><br></div>To get fair benchmarks, those extension modules should be rewritten,</div><div class="gmail_extra">
with cffi for example: its C calls have very little overhead,</div><div class="gmail_extra">and it integrates very well with the rest of the PyPy interpreter.</div><div class="gmail_extra"><div><br></div>-- <br>Amaury Forgeot d'Arc
</div></div>