Update comment on prediction macros.

1 files changed, 13 insertions, 11 deletions

diff --git a/Python/ceval.c b/Python/ceval.c
index 037c86c..a9e37ae 100644
--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -615,18 +615,20 @@ PyEval_EvalFrameEx(PyFrameObject *f, int throwflag)
 	COMPARE_OP is often followed by JUMP_IF_FALSE or JUMP_IF_TRUE.  And,
 	those opcodes are often followed by a POP_TOP.
 
-	Verifying the prediction costs a single high-speed test of register
+	Verifying the prediction costs a single high-speed test of a register
 	variable against a constant.  If the pairing was good, then the
-	processor has a high likelihood of making its own successful branch
-	prediction which results in a nearly zero overhead transition to the
-	next opcode.
-
-	A successful prediction saves a trip through the eval-loop including
-	its two unpredictable branches, the HAS_ARG test and the switch-case.
-
-        If collecting opcode statistics, turn off prediction so that
-	statistics are accurately maintained (the predictions bypass
-	the opcode frequency counter updates).
+	processor's own internal branch predication has a high likelihood of
+	success, resulting in a nearly zero-overhead transition to the
+	next opcode.  A successful prediction saves a trip through the eval-loop
+	including its two unpredictable branches, the HAS_ARG test and the 
+	switch-case.  Combined with the processor's internal branch prediction,
+	a successful PREDICT has the effect of making the two opcodes run as if 
+	they were a single new opcode with the bodies combined.
+
+    If collecting opcode statistics, your choices are to either keep the
+	predictions turned-on and interpret the results as if some opcodes
+	had been combined or turn-off predictions so that the opcode frequency
+	counter updates for both opcodes.
 */
 
 #ifdef DYNAMIC_EXECUTION_PROFILE