<div dir="ltr">Thanks, Nick -- that's interesting. I just saw the extra JUMP_FORWARD and JUMP_ABSOLUTE instructions on my commute home (I guess those are something Python 3.x optimizes away).<div><br></div><div>VERY strangely, on Windows Python 2.7 is faster! Comparing 64-bit Python 2.7.12 against Python 3.5.3 on my Windows 10 laptop:</div><div><br></div><div>* Python 2.7.12: <span style="font-size:12.8px">4.088s</span></div><div><div style="font-size:12.8px">* Python 3.5.3: <span style="font-size:12.8px">5.792s</span></div></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px">I'm pretty sure MSVC/Windows doesn't support computed gotos, but that doesn't explain why 3.5 is so much faster than 2.7 on Mac. I have yet to try it on Linux.</div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">-Ben</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 18, 2017 at 9:35 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19 July 2017 at 02:18, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> On Tue, 18 Jul 2017 12:03:36 -0400<br>
> Ben Hoyt <<a href="mailto:benhoyt@gmail.com">benhoyt@gmail.com</a>> wrote:<br>
</span><span class="">>> The program is a pentomino puzzle solver, and it works via code generation,<br>
>> generating a ton of nested "if" statements, so I believe it's exercising<br>
>> the Python bytecode interpreter heavily.<br>
><br>
> A first step would be to see if the generated bytecode has changed<br>
> substantially.<br>
<br>
</span>Scanning over them, the Python 2.7 bytecode appears to have many more<br>
JUMP_FORWARD and JUMP_ABSOLUTE opcodes than appear in the 3.6 version<br>
(I didn't dump them into a Counter instance to tally them properly<br>
though, since 2.7's dis module is missing the structured opcode<br>
iteration APIs).<br>
<br>
With the shift to wordcode, the overall size of the bytecode is also<br>
significantly *smaller*:<br>
<br>
>>> len(co.co_consts[0].co_code) # 2.7<br>
14427<br>
<br>
>>> len(co.co_consts[0].co_code) # 3.6<br>
11850<br>
<br>
However, I'm not aware of any Python profilers that currently offer<br>
opcode level profiling - the closest would probably be VMProf's JIT<br>
profiling, and that aspect of VMProf is currently PyPy specific<br>
(although could presumably be extended to CPython 3.6+ by way of the<br>
opcode evaluation hook).<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/benhoyt%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>benhoyt%40gmail.com</a><br>
</div></div></blockquote></div><br></div>