<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 19, 2013 at 2:07 AM, Maciej Fijalkowski <span dir="ltr"><<a href="mailto:fijall@gmail.com" target="_blank">fijall@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>


><br>
><br>
><br>
> On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah <<a href="mailto:stefan@bytereef.org">stefan@bytereef.org</a>> wrote:<br>
>><br>
>> Maciej Fijalkowski <<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>> wrote:<br>
>> > I would like to discuss on the language summit a potential inclusion<br>
>> > of cffi[1] into stdlib. This is a project Armin Rigo has been working<br>
>> > for a while, with some input from other developers.<br>
>><br>
>> I've tried cffi (admittedly only in a toy script) and find it very nice<br>
>> to use.<br>
>><br>
>> Here's a comparison (pi benchmark) between wrapping libmpdec using a<br>
>> C-extension (_decimal), cffi and ctypes:<br>
>><br>
>><br>
>> +-------------------------------+----------+----------+---------+<br>
>> |                               | _decimal |  ctypes  |   cffi  |<br>
>> +===============================+==========+==========+=========+<br>
>> | cpython-tip (with-system-ffi) |   0.19s  |   5.40s  |  5.14s  |<br>
>> +-------------------------------+----------+----------+---------+<br>
>> | cpython-2.7 (with-system-ffi) |    n/a   |   4.46s  |  5.18s  |<br>
>> +-------------------------------+----------+----------+---------+<br>
>> |      Ubuntu-cpython-2.7       |    n/a   |   3.63s  |    -    |<br>
>> +-------------------------------+----------+----------+---------+<br>
>> |      pypy-2.2.1-linux64       |    n/a   |  125.9s  |  0.94s  |<br>
>> +-------------------------------+----------+----------+---------+<br>
>> |     pypy3-2.1-beta1-linux64   |    n/a   |  264.9s  |  2.93s  |<br>
>> +-------------------------------+----------+----------+---------+<br>
>><br>
>><br>
>> I guess the key points are that C-extensions are hard to beat and that<br>
>> cffi performance on pypy-2 is outstanding. Additionally it's worth noting<br>
>> that Ubuntu does something in their Python build that we should do, too.<br>
><br>
><br>
> Ubuntu compiles their Python with FDO (feedback directed optimization /<br>
> profile guided optimization) enabled. All distros should do this if they<br>
> don't already. It's generally 20% interpreter speedup. Our makefile already<br>
> supports it but it isn't the default build as it takes a long time given<br>
> that it needs to compile everything twice and do a profiled benchmark run<br>
> between compilations.<br>
><br>
> -gps<br>
<br>
</div></div>Hey Greg.<br>
<br>
We found out that this only speedups benchmarks that you tried during<br>
profiling and not others, so we disabled it for the default pypy<br>
build. Can you provide me with some more detailed study on how it<br>
speeds up interpreters in general and CPython in particular?<br></blockquote><div><br></div><div>That's a common concern for profile based builds but it turns out not to matter a whole lot which workloads you choose for the CPython interpreter to collect profiles for a FDO build. I believe ubuntu's packages just use the test suite. In our own tests at work this produced good results. Interpreter loops and other common code paths in the interpreter have a *lot* of low hanging fruit in terms of more optimal code generation.</div>

<div><br></div><div>Link time optimization adds additional benefits IF you can get it working (not always easy or reliable right now as Matthias mentions in issue17781).</div><div><br></div><div>-gps</div><div><br></div>
</div>
</div></div>