On Nov 23, 2015 21:12, "Mikhail T." <mi+t...@aldan.algebra.com> wrote: > > On 23.11.2015 19:43, Yann Ylavic wrote: >> >> No measured difference in my tests, I guess it depends on likelyhood to fail/succeed early in the string or not. > > ? I don't see, where it wins anything -- but I do see, where it loses a little... > >> That's expected (or at least no cared about in this test case). We simply want res to not be optimized out, so print it before leaving, without any particular relevance for its value (string.h and optimized versions should return the same res with the same args, ascii strings only, though). > > Yes, we do want the value printed -- such as to catch the kind of errors I reported earlier. But my question was, why does the value change depending on the number of iterations?
L1 cache and other direct effects of cpu internal optimization. You would be better off introducing a non-optimizable operation consuming most cpu registers and the L1 cache between iterations if you want to predict the non-repeditive invocation of this function in different contexts throughout the processing phases.
