2013/6/3 <[email protected]> > Now the non-DBC :-) > > I don't think using deoptimization and type feedback is the right way > forward > with switch/case constructs at this point. There is much lower-hanging > fruit > that shouldn't require any (or at least minimal) platform-specific, > low-level > compiler changes, that apply to many more cases, and that should achieve > similar > performance results to what your patch does. > > There are handful of "standard" compiler techniques to optimize switch > statements, e.g. using a binary search of the case labels, hash codes for > string > case labels and jump tables for large mostly contiguous case label sets. > These > standard techniques should be applied before reaching for the type feedback > hammer. Biased case label checks before starting a binary label search > could be > used someday to squeeze a little extra performance out, but I think it's > clumsy > overkill to do that work now without the "standard" set of optimizations > as a > basis, and even more so if you rely on a new custom deoptimization > mechanism to > do so. > > I disagree here: I think in a JS world, the "standard" optimizations are the big hammer. They also only work really well for C-like switches. Collecting dynamic feedback is IMO the light-weight approach to get to good performance without spending a lot of time in the optimizing compiler. Of course deoptimization needs to be considered carefully, but in general counting frequencies in the full-codegen and using them to guide the optimizing compiler achieves the performance much easier.
I don't see much unnecessary complexity with the approach taken here. Most of the code is boilerplate for adding an instruction to the IR (and as Danno mentioned could be possibly simplified further) The fact that none of the V8 benchmarks actually use switch-statements (except a tiny one in DeltaBlue, which does not affect performance at all) should not count against this CL, because with the same argument would apply to any optimization of switch. Of course a table-based lookup will work well for extremely large switch statements, but in the example mentioned above (~20 clauses) it will most likely not outperform the comparisons weighted by frequency. I have an old CL for table-based switch sitting around somewhere, but it's too outdated to be applied right away) > That being said, I'd welcome patches that implemented any of the standard > techniques that I've mentioned above. :-) > > > https://codereview.chromium.**org/16128004/diff/22001/src/** > hydrogen-instructions.h<https://codereview.chromium.org/16128004/diff/22001/src/hydrogen-instructions.h> > File src/hydrogen-instructions.h (right): > > https://codereview.chromium.**org/16128004/diff/22001/src/** > hydrogen-instructions.h#**newcode107<https://codereview.chromium.org/16128004/diff/22001/src/hydrogen-instructions.h#newcode107> > src/hydrogen-instructions.h:**107: V(DeoptCounter) > \ > In addition to my general feedback to your approach, here's some > feedback about the implementation: We are generally trying to reduce the > number of hydrogen instructions, not increase them. If you want to > manipulate data counters form Hydrogen code and then trigger a > deoptimization, then you should use HLoad/HStore/HAdd instructions > followed by a "normal" deopt or a call to a runtime function that does > the necessary bookkeeping and then does a lazy deopt... both approaches > don't require any new platform-specific code. > > > https://codereview.chromium.**org/16128004/<https://codereview.chromium.org/16128004/> > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/**group/v8-dev<http://groups.google.com/group/v8-dev> > ---You received this message because you are subscribed to the Google > Groups "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > v8-dev+unsubscribe@**googlegroups.com<v8-dev%[email protected]> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
