home on the range

You usually want to stay below 35 instructions per method, to get them inlined when hot.

On Tue, Dec 13, 2011 at 12:29 PM, Paul Phillips <paulp@improving.org> wrote:

One last installment in the range monologues.  I knew that commit
inflated code size (see attached) but the tea leaves are telling me
that having a highly optimizable inner loop is the most important
thing by a good measure.  So that's why it's put together the way that
it is.  I imagine we can cut down the redundancy a bit, but there
seems to be some kind of cliff hotspot maniacally drives you off if
you introduce much more logic.

Attached is the bytecode diff before and after that change.  In both
incarnations, the distribution was built optimized, then that
optimized compiler was used to build itself, optimized.

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

On Tue, Dec 13, 2011 at 03:29:37AM -0800, Paul Phillips wrote:
> One last installment in the range monologues. I knew that commit
> inflated code size (see attached) but the tea leaves are telling me
> that having a highly optimizable inner loop is the most important
> thing by a good measure. So that's why it's put together the way that
> it is. I imagine we can cut down the redundancy a bit, but there
> seems to be some kind of cliff hotspot maniacally drives you off if
> you introduce much more logic.

Reading commit 4cfc633f one thing I'm curious about is the following:

128 /** !!! These methods must be public or they will not be inlined.
129 * But they are certainly not intended to be part of the API.
130 * This collision between inlining requirements and access semantics
131 * is highly unfortunate and must be resolved.
132 *
133 * Proposed band-aid: an @internal annotation.
134 */

Is this a reference to SI-4767 [1]? That bug is listed as open,
although the final comment (from the 4th of July) seems to indicate
that Paul wanted it closed.

Or is this some other issue? If private methods aren't currently inlined
(even with the @inline annotation) it would be good to know.

On Tue, Dec 13, 2011 at 8:17 AM, Erik Osheim wrote:
> Is this a reference to SI-4767 [1]? That bug is listed as open,
> although the final comment (from the 4th of July) seems to indicate
> that Paul wanted it closed.

I reopened it yesterday to remind me to give it a closer look.
However this is not the same issue. That ticket was about private
methods not being inlined even in the same class. The issue with the
soon-to-be-short-lived range implementation is the indirect inlining
of private methods in another class (that is, foreach is inlined into
some caller, and foreachFoo needs to be inlined into that - and the
inliner objects.)

On Tue, Dec 13, 2011 at 08:23:30AM -0800, Paul Phillips wrote:
> However this is not the same issue. That ticket was about private
> methods not being inlined even in the same class. The issue with the
> soon-to-be-short-lived range implementation is the indirect inlining
> of private methods in another class (that is, foreach is inlined into
> some caller, and foreachFoo needs to be inlined into that - and the
> inliner objects.)

Ah, that makes sense. Thanks for the explanation.