> On Nov 4, 2015, at 1:43 PM, Alfonso Guerra <hupernike...@gmail.com> wrote: > > > > On Wed, Nov 4, 2015 at 1:22 PM, Filip Pizlo <fpi...@apple.com > <mailto:fpi...@apple.com>> wrote: > >> On Nov 4, 2015, at 10:03 AM, Alfonso Guerra <hupernike...@gmail.com >> <mailto:hupernike...@gmail.com>> wrote: >> >> was ~20% faster on my machine. > > 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? > > 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%.
Sounds like noise. I bet the generated code is identical. > > 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. 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. The only time when ++x is better is for iterators that don’t have a postincrement operator. 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. -Filip
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
