On Fri, Feb 6, 2015 at 10:30 AM, Steve Fink <sf...@mozilla.com> wrote:
> This looks awesome! > > What are the important limitations? I'm guessing it's not going to help > detect that if only X were true, the register allocator would have avoided > spilling any registers. I suppose that doesn't fit into "high-level > optimization decisions". But what sorts of things could have a large impact > on performance that this cannot handle? > Ironically it is those true optimization passes (GVN, regalloc, LICM) that optimization tracking currently does not track. If something dominates execution time because it was unable to be hoisted out of a loop, there is no reporting currently that lets you know it was possibly due to LICM failing. What's landed is squaredly aimed at the frequent yet catastrophic "surface" failures, like being unable to optimize a getprop or being unable to inline a native. > > It looks like right now the TrackedStrategy is going to be very unstable. > What policy is there for updating it (eg append only)? Do we need a new > subtrahend to increment? Or is there a mapping layer to mitigate the API > instability? How much does it matter? That's good foresight! We're not yet at the stage of hooking it up the frontend performance tool. Currently I'm stringifying all the performance reasons when emitting the JSON of the profile, so stability of the enums doesn't matter. To save on space of the profile, it may be desirable only emit the enum numerals. Append-only seems like the easiest policy to me. Until we hook it up though, there is no policy for updating the enums. > > > On 02/05/2015 04:20 PM, Shu-yu Guo wrote: > >> Greetings, fellow subtrahend incrementers! >> >> I recently landed bug 1030389 to track the high-level optimizations >> decisions >> (i.e., deciding what MIR is emitted) made by IonBuilder. This information >> will feed into the profiler and is attached to sampled JIT frames. >> >> Currently, getprop, setprop, getelem, setelem, and calls are tracked. I >> should >> like to introduce the API here so that upcoming patches of new >> optimizations >> like the SIMD.js optimizations are tracked from the beginning. >> >> High-level description >> ---------------------- >> >> Optimizations are tracked by bytecode location. The API allows each >> bytecode >> location to track two things: optimization attempts, and type information. >> >> Each optimization attempt is is a pair of (strategy, outcome). These are >> implemented by the enums TrackedStrategy and TrackedOutcome in >> js/public/TrackedOptimizationInfo.h. The strategy describes the >> optimization >> Ion is attempting to emit (e.g., a definite slot load), and the outcome >> describes a specific reason for its success or failure (e.g., failed due >> to >> no type info). >> >> Each bytecode location can accumulate a list of attempts. This list is >> terminated by the first successful attempt. The slow path is not encoded >> as >> its own attempt pair and is inferred from a list of attempts whose >> outcomes >> are all failures. That is, if only the slow path succeeded, the attempts >> list >> will all failed attempts. >> >> Each tracked type is a triple of (site, MIR type, type set). The site is >> described by the enum TrackedTypeSite. >> >> API >> --- >> >> Add the specific attempts, outcomes, and type sites you need, if not >> already >> present, to the enums in js/public/TrackedOptimizationInfo.h. >> >> To start tracking optimizations for a bytecode location, >> call |startTrackingOptimizations()|. >> >> Usually, types are tracked in the beginning by >> calling |trackTypeInfo(TrackedTypeSite, MIRType, TypeSet *)|. >> >> Before attempting to apply a strategy (e.g., before the call to >> getPropTryConstant), call |trackOptimizationAttempt(TrackedStrategy)|. By >> default, the outcome of the attempt is "generic failure". To refine the >> outcome, call |trackOptimizationOutcome(TrackedOutcome)|. >> >> There is the convenience function |trackOptimizationSuccess()| to track >> successes. Be sure to call this on successfully applying an optimization! >> In >> methods like IonBuilder::jsop_getprop where a series of strategies are >> tried >> one after another, each |*emitted = true| assignment should be accompanied >> by >> a call to |trackOptimizationSuccess()|. >> >> All tracking methods are infallible. OOM during tracking disables >> optimization >> tracking instead. >> >> That's it! Instrumentation bugs also make great first bugs, and I would be >> happy to mentor. >> >> > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > -- shu _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
