[webkit-dev] Proposal for serializing alpha channel values; request for algorithm help

[Filip Pizlo]

> On Nov 4, 2015, at 1:43 PM, Alfonso Guerra <huperniketes at gmail.com> wrote:
> 
> 
> 
> On Wed, Nov 4, 2015 at 1:22 PM, Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> wrote:
> 
>> On Nov 4, 2015, at 10:03 AM, Alfonso Guerra <huperniketes at gmail.com <mailto:huperniketes at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151104/6bd6819c/attachment.html>