<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 2, 2017 at 4:01 AM, Mark Morgan Lloyd <span dir="ltr"><<a href="mailto:markMLl.fpc-pascal@telemetry.co.uk" target="_blank">markMLl.fpc-pascal@telemetry.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
It's interesting that the real (wallclock) and user times are consistently in a different sequence. /If/ the user time is to be believed, there's a very small advantage to counting down even if the sequence you want is ascending (i.e. test3) rather than simply counting up.</blockquote><div> </div><div>Not looking at the assembly either, but I'd assume it's because you can do a simple test for zero in the count down case, and have to do a compare against a value and then test the result on count up, which probably takes an extra instruction or two.  The optimization can sometimes convert everything to count down as part of the setup of the loop (I know in Delphi you'd sometimes see loops run the other way in the debugger when there was no behavioral change in function).  I guess since in your examples the final contents of the a variable after the loop exits depends on direction, then it couldn't do this for the count up loops.  Maybe try again with Inc(a) in the body?</div><div><br></div><div>Jeff.</div></div><br></div></div>