Changeset 147511 in webkit


Ignore:
Timestamp:
Apr 2, 2013 5:34:31 PM (11 years ago)
Author:
ggaren@apple.com
Message:

DFG should compile a little sooner
https://bugs.webkit.org/show_bug.cgi?id=113835

Reviewed by Michael Saboff.

2% speedup on SunSpider.

2% speedup on JSRegress.

Neutral on Octane, v8, and Kraken.

The worst-hit single sub-test is kraken-stanford-crypto-ccm.js, which gets
18% slower. Since Kraken is neutral overall in its preferred mean, I
think that's OK for now.

(Our array indexing speculation fails pathologically on
kraken-stanford-crypto-ccm.js. Compiling sooner is a regression because
it triggers those failures sooner. I'm going to file some follow-up bugs
explaining how to fix our speculations on this sub-test, at which point
compiling earlier should become a slight speedup on Kraken overall.)

  • bytecode/CodeBlock.cpp:

(JSC::CodeBlock::optimizationThresholdScalingFactor): I experimented
with a few different options, including reducing the coefficient 'a'.
A simple linear reduction on instruction count worked best.

Location:
trunk/Source/JavaScriptCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/JavaScriptCore/ChangeLog

    r147349 r147511  
     12013-04-02  Geoffrey Garen  <ggaren@apple.com>
     2
     3        DFG should compile a little sooner
     4        https://bugs.webkit.org/show_bug.cgi?id=113835
     5
     6        Reviewed by Michael Saboff.
     7
     8        2% speedup on SunSpider.
     9
     10        2% speedup on JSRegress.
     11
     12        Neutral on Octane, v8, and Kraken.
     13
     14        The worst-hit single sub-test is kraken-stanford-crypto-ccm.js, which gets
     15        18% slower. Since Kraken is neutral overall in its preferred mean, I
     16        think that's OK for now.
     17
     18        (Our array indexing speculation fails pathologically on
     19        kraken-stanford-crypto-ccm.js. Compiling sooner is a regression because
     20        it triggers those failures sooner. I'm going to file some follow-up bugs
     21        explaining how to fix our speculations on this sub-test, at which point
     22        compiling earlier should become a slight speedup on Kraken overall.)
     23
     24        * bytecode/CodeBlock.cpp:
     25        (JSC::CodeBlock::optimizationThresholdScalingFactor): I experimented
     26        with a few different options, including reducing the coefficient 'a'.
     27        A simple linear reduction on instruction count worked best.
     28
    1292013-04-01  Benjamin Poulain  <benjamin@webkit.org>
    230
  • trunk/Source/JavaScriptCore/bytecode/CodeBlock.cpp

    r147190 r147511  
    29382938double CodeBlock::optimizationThresholdScalingFactor()
    29392939{
    2940     // This expression arises from doing a least-squares fit of
     2940    // This expression originally arose from doing a least-squares fit of
    29412941    //
    29422942    // F[x_] =: a * Sqrt[x + b] + Abs[c * x] + d
     
    29522952    // 10000       6.0          (similar to above)
    29532953    //
    2954     // I achieve the minimization using the following Mathematica code:
     2954    // Since then, as compile times have gone down and optimization value has gone up, we've
     2955    // tweaked the function to favor earlier compilation.
     2956    //
     2957    // What follows is a complete description of how to reproduce the original coefficients:
     2958    //
     2959    // I achieved the minimization using the following Mathematica code:
    29552960    //
    29562961    // MyFunctionTemplate[x_, a_, b_, c_, d_] := a*Sqrt[x + b] + Abs[c*x] + d
     
    29922997    // term because Sqrt represents my intution that the function should be more sensitive
    29932998    // to small changes in small values of x, but less sensitive when x gets large.
    2994    
     2999    //
    29953000    // Note that the current fit essentially eliminates the linear portion of the
    29963001    // expression (c == 0.0).
     3002
    29973003    const double a = 0.061504;
    29983004    const double b = 1.02406;
    29993005    const double c = 0.0;
    30003006    const double d = 0.825914;
    3001    
    3002     double instructionCount = this->instructionCount();
    3003    
    3004     ASSERT(instructionCount); // Make sure this is called only after we have an instruction stream; otherwise it'll just return the value of d, which makes no sense.
    3005    
    3006     double result = d + a * sqrt(instructionCount + b) + c * instructionCount;
     3007    const double instructionRatio = 0.8;
     3008   
     3009    double x = instructionCount() * instructionRatio;
     3010   
     3011    ASSERT(x); // Make sure this is called only after we have an instruction stream; otherwise it'll just return the value of d, which makes no sense.
     3012   
     3013    double result = d + a * sqrt(x + b) + c * x;
    30073014#if ENABLE(JIT_VERBOSE_OSR)
    3008     dataLog(*this, ": instruction count is ", instructionCount, ", scaling execution counter by ", result, " * ", codeTypeThresholdMultiplier(), "\n");
     3015    dataLog(*this, ": instruction count is ", instructionCount(), ", scaling execution counter by ", result, " * ", codeTypeThresholdMultiplier(), "\n");
    30093016#endif
    30103017    return result * codeTypeThresholdMultiplier();
Note: See TracChangeset for help on using the changeset viewer.