Eric, I think that you are on the right track by trying to measure the effectiveness of each optimization -- even if we need to more data to increase the accuracy.
On Fri, Sep 3, 2010 at 6:02 AM, Eric Ayers <zun...@google.com> wrote: > I was thinking about how keeping track of the AST size on the fly could be > expensive and complicated. The simplest thing to do would be to have to add > in a separate walk that just counted nodes, maybe once at the head of > optimizeLoop. I wrote this dummy code earlier to measure the cost of just a > walk, and it turns out that walking the tree and counting all nodes is a > computationally significant amount of work - its like adding an extra > optimizer. I didn't want to have too much observer effect if the change is > just for statistical purposes. (but maybe I could add that walk just in the > case of having tracing enabled.) > > But I mis-spoke when describing my goal as tuning code size to compile > time. I'm really just trying to find ways to shorten the compile time. > You've mentioned a couple of times about the optimizations being quadratic > cost. I want to use this feature to add an option with a "decent" amount of > optimization and shave off a significant amount of the compile time. > Something between draftCompile and fully optimized. The decision point to > opt out of the build to could be specific to each optimizer. For example, > if each optimizer declares that isn't doing "much" through a single or two > consecutive passes, it might be time to throw in the towel. We could have > users specify an optimization level: -O, -O2, -O3, ... like c compilers and > gzip do to specify the amount of optimization desired. > > At the water cooler we've speculated that there might be interaction > between optimizers we can predict. e.g. dead code elimination isn't going > to do much if the pruner and type tightener weren't very effective on the > last pass (I just made that up). Early in my investigations I was hoping > that we could just stop calling some of the optimizers that aren't very > effective after the first few passes, but the only visibility I had was the > didChange boolean. Now we could do some statistics gathering on different > apps and see if that would be worth pursuing. > > -Eric. > > On Fri, Sep 3, 2010 at 12:02 AM, Ray Cromwell <cromwell...@gmail.com>wrote: > >> >> I think it's useful to see the amount of work done vs time spent, but I >> don't think it will help automate size-tradeoffs unless you keep track of >> the size of the AST as well, so that you can see roughly how much it's being >> reduced each pass. Some optimizations don't really shrink the AST size, but >> enable other optimizations. e.g. type tightening, finalizing, and >> static-fying help method inliner, DCE, and pruner. It would be nice to >> correlate, for example, with and without those tightening/staticifying >> passes, how much worst the actual code-deleting passes would be, because >> that's the only real way if you know they're worth it. >> >> Some things have an effect far down the chain, for example, static-methods >> can be obfuscated better, because 'this' can't be obfuscated, so you don't >> see the code-size effect symbol obfuscation, as AST size doesn't tell the >> whole story. >> >> -Ray >> >> >> On Thu, Sep 2, 2010 at 8:48 PM, Eric Ayers <zun...@google.com> wrote: >> >>> I'm looking for feedback on this proposed change, mainly, is the >>> statistical information worth the added complexity? Currently, this only >>> dumps out a diagnostic when you specify >>> >>> >>> >>> -Dgwt.jjs.traceMethods=com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimize >>> >>> on the Compiler command line. Here's a sample of what the statistical >>> output looks like on a minimal GWT app: >>> >>> Pass 1 ---- ( 0/ 0) >>> Pruner 27.94% ( 3132/ 11211) Finalizer 45.64% ( 2455/ >>> 5379) MakeCallsStatic 7.94% ( 812/ 10229) TypeTightener 2.41% ( 1226/ >>> 50966) MethodCallTightener 1.96% ( 70/ 3569) DeadCodeElimination 1.93% >>> ( 1277/ 66324) MethodInliner 28.84% ( 5430/ 18830) >>> SameParameterValueOptimizer 0.58% ( 44/ 7588) >>> Pass 2 ---- ( 0/ 0) >>> Pruner 12.24% ( 1089/ 8895) Finalizer 0.09% ( 4/ >>> 4400) MakeCallsStatic 2.68% ( 182/ 6796) TypeTightener 0.80% ( 272/ >>> 33915) MethodCallTightener 1.36% ( 32/ 2353) DeadCodeElimination 0.41% >>> ( 166/ 40201) MethodInliner 9.95% ( 956/ 9609) >>> SameParameterValueOptimizer 0.24% ( 14/ 5776) >>> Pass 3 ---- ( 0/ 0) >>> Pruner 1.79% ( 240/ 13392) Finalizer 0.00% ( 0/ >>> 4036) MakeCallsStatic 0.50% ( 31/ 6221) TypeTightener 0.31% ( 62/ >>> 20088) MethodCallTightener 0.05% ( 1/ 2190) DeadCodeElimination 0.20% >>> ( 74/ 37391) MethodInliner 2.90% ( 250/ 8608) >>> SameParameterValueOptimizer 0.11% ( 6/ 5325) >>> Pass 4 ---- ( 0/ 0) >>> Pruner 0.54% ( 57/ 10492) Finalizer 0.03% ( 1/ >>> 3948) MakeCallsStatic 0.02% ( 1/ 6086) TypeTightener 0.05% ( 8/ >>> 14660) MethodCallTightener 0.05% ( 1/ 2147) DeadCodeElimination 0.47% >>> ( 173/ 36545) MethodInliner 2.07% ( 172/ 8310) >>> SameParameterValueOptimizer 0.02% ( 1/ 5126) >>> Pass 5 ---- ( 0/ 0) >>> Pruner 0.67% ( 66/ 9896) Finalizer 0.03% ( 1/ >>> 3747) MakeCallsStatic 0.02% ( 1/ 5732) TypeTightener 0.01% ( 2/ >>> 13845) MethodCallTightener 0.00% ( 0/ 2012) DeadCodeElimination 0.05% >>> ( 19/ 35210) MethodInliner 0.20% ( 16/ 8001) >>> SameParameterValueOptimizer 0.00% ( 0/ 4976) >>> Pass 6 ---- ( 0/ 0) >>> Pruner 0.30% ( 22/ 7338) Finalizer 0.00% ( 0/ >>> 3695) MakeCallsStatic 0.00% ( 0/ 5691) TypeTightener 0.07% ( 9/ >>> 13660) MethodCallTightener 0.00% ( 0/ 2001) DeadCodeElimination 0.06% >>> ( 13/ 23220) MethodInliner 0.00% ( 0/ 2638) >>> SameParameterValueOptimizer 0.00% ( 0/ 4938) >>> Pass 7 ---- ( 0/ 0) >>> Pruner 0.10% ( 5/ 4890) Finalizer 0.00% ( 0/ >>> 3688) MakeCallsStatic 0.04% ( 2/ 5690) TypeTightener 0.00% ( 0/ >>> 4548) MethodCallTightener 0.00% ( 0/ 2001) DeadCodeElimination 0.00% >>> ( 0/ 11605) MethodInliner 0.38% ( 20/ 5283) >>> SameParameterValueOptimizer 0.00% ( 0/ 4937) >>> Pass 8 ---- ( 0/ 0) >>> Pruner 0.04% ( 2/ 4886) Finalizer 0.00% ( 0/ >>> 3686) MakeCallsStatic 0.00% ( 0/ 5684) TypeTightener 0.01% ( 1/ >>> 9093) MethodCallTightener 0.00% ( 0/ 1999) DeadCodeElimination 0.00% >>> ( 0/ 11601) MethodInliner 0.00% ( 0/ 2634) >>> SameParameterValueOptimizer 0.00% ( 0/ 4933) >>> Pass 9 ---- ( 0/ 0) >>> Pruner 0.00% ( 0/ 2443) Finalizer 0.00% ( 0/ >>> 3686) MakeCallsStatic 0.00% ( 0/ 5684) TypeTightener 0.00% ( 0/ >>> 4546) MethodCallTightener 0.00% ( 0/ 1999) DeadCodeElimination 0.00% >>> ( 0/ 11601) MethodInliner 0.00% ( 0/ 2634) >>> SameParameterValueOptimizer 0.00% ( 0/ 4933) >>> DataflowOptimizer 0.46% ( 5/ 1080) >>> >>> I think the information is interesting on its own, but it could prove >>> useful if we decide to implement a compiler option to allow users to make a >>> compilation time/code size output trade off. Our current options are either >>> minimal optimization or maximum possible optimization. We could probably >>> cut the production compile down a bit if we had an in-between option (and >>> maybe made it the default). >>> >>> In a couple of places, I got rid of the didChange() overload on >>> JModVisitor subclasses. I know that there is a difference, I'm wondering if >>> it is important. >>> >>> My eclipse environment is a mess - please don't bother with code >>> formatting feedback until I dig myself out from under it. >>> >>> -Eric. >>> >>> On Thu, Sep 2, 2010 at 11:38 PM, <zun...@google.com> wrote: >>> >>>> Reviewers: scottb, robertvawter, cromwellian, >>>> >>>> Description: >>>> RR: Add statistics to optimizers >>>> >>>> Updates the compiler optimizers to returns statistics about each pass >>>> instead of a simple boolean. This could be used to analyze >>>> the effectiveness of an individual optimizer, tune the compiler >>>> for code size/ compile time trade offs, or predict the effectiveness >>>> of future passes of an optimizer. >>>> >>>> >>>> Please review this at http://gwt-code-reviews.appspot.com/841801/show >>>> >>>> Affected files: >>>> M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java >>>> M dev/core/src/com/google/gwt/dev/jjs/ast/JModVisitor.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/DeadCodeElimination.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/Finalizer.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/LongCastNormalizer.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/MethodCallTightener.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java >>>> A dev/core/src/com/google/gwt/dev/jjs/impl/OptimizerStats.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java >>>> M >>>> dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java >>>> M dev/core/src/com/google/gwt/dev/jjs/impl/gflow/DataflowOptimizer.java >>>> M >>>> dev/core/src/com/google/gwt/dev/jjs/impl/gflow/liveness/LivenessTransformation.java >>>> M >>>> dev/core/src/com/google/gwt/dev/jjs/impl/gflow/unreachable/DeleteNodeVisitor.java >>>> >>>> >>>> >>> >>> >>> -- >>> Eric Z. Ayers >>> Google Web Toolkit, Atlanta, GA USA >>> >>> >> > > > -- > Eric Z. Ayers > Google Web Toolkit, Atlanta, GA USA > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
