[Patches] [ python-Patches-1443159 ] Remove bad PREDICT in ceval.c

[SourceForge.net]

Patches item #1443159, was opened at 2006-03-04 13:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Remove bad PREDICT in ceval.c

Initial Comment:
The current FOR_ITER -> UNPACK_SEQUENCE prediction is
only right 6.41% of the time (212 million opcodes
analysed). This patch removes it.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-06 19:02

Message:
Logged In: YES 
user_id=80475

Collin, you are welcome to write to me directly to discuss 
the results of your dynamic analysis. I suspect your 
results are almost certainly incorrect.  The prediction 
was originally added after a detailed analysis of a great 
deal of Python code and checking the results of multiple 
pieces of benchmark code.  Please do not arbitrarily start 
removing these unless you're damned certain the original 
study was erronenous.

Also, I suspect that the given percentage does not reflect 
the conditional probability of the preceding PREDICT
(STORE_FAST).  The overwhelming majority of cases needing 
optimization involve "for x in iterable" where x is a fast 
local.  If that prediction fails, then the next most 
common case is "for x,y in iterable".  The latter is 
highly likely whenever we know the former has not 
occured.  IOW, the unpack sequence may only come up 6% of 
the time, but its conditional probability rises above 90% 
when it follows the other prediction.

Also, take some case with dynamic analysis.  It is always 
tricky because it is very difficult to find truly 
representative code and to not have a single anomalous 
case run over and over again.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-06 18:42

Message:
Logged In: YES 
user_id=33168

Raymond any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443159&group_id=5470