<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 4, 2015, at 1:43 PM, Alfonso Guerra <<a href="mailto:huperniketes@gmail.com" class="">huperniketes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 4, 2015 at 1:22 PM, Filip Pizlo <span dir="ltr" class=""><<a href="mailto:fpizlo@apple.com" target="_blank" class="">fpizlo@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Nov 4, 2015, at 10:03 AM, Alfonso Guerra <<a href="mailto:huperniketes@gmail.com" target="_blank" class="">huperniketes@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">was ~20% faster on my machine.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">It’s very surprising that this made any difference. Compilers are ordinarily smart enough to understand the equivalence of ++x and x++ if the result is unused. Are you sure you compiled with optimizations enabled?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I hadn't. With full optimizations and tweaking of the driver to prevent the compiler from optimizing away invocation of the functions entirely, the difference is only ~1.3-3.3%.</div></div></div></div></div></blockquote><div><br class=""></div><div>Sounds like noise. I bet the generated code is identical.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">No longer as substantial. It beats Lightspeed C, but it's best not to depend on optimization for code which is modeled on an obsolete processor architecture, and is so easy to write. Doubly so when using non-optimized builds for development.</div></div></div></div></div></blockquote><div><br class=""></div><div>It is good practice to depend on those compiler optimizations that are trivial and guaranteed in any modern compiler. That’s why we do things like use inline methods and templates for abstractions, rely on return value optimization, express constants using foldable expressions (like const unsigned million = 1000 * 1000) when it illustrates the point, etc. x++ is no different. In fact, any optimization that round-trips the code through SSA will convert x++ to ++x implicitly.</div><div><br class=""></div><div>The only time when ++x is better is for iterators that don’t have a postincrement operator.</div><div><br class=""></div><div>We don’t usually make changes to the code to optimize non-optimized builds. If anything, we do the opposite - non-optimized WebKit builds tend to have a ton of assertions that slow things down a lot.</div><div><br class=""></div><div>-Filip</div><div><br class=""></div></div></body></html>