Title: [147511] trunk/Source/_javascript_Core
Revision
147511
Author
[email protected]
Date
2013-04-02 17:34:31 -0700 (Tue, 02 Apr 2013)

Log 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.

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (147510 => 147511)


--- trunk/Source/_javascript_Core/ChangeLog	2013-04-03 00:28:58 UTC (rev 147510)
+++ trunk/Source/_javascript_Core/ChangeLog	2013-04-03 00:34:31 UTC (rev 147511)
@@ -1,3 +1,31 @@
+2013-04-02  Geoffrey Garen  <[email protected]>
+
+        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.
+
 2013-04-01  Benjamin Poulain  <[email protected]>
 
         Use Vector::reserveInitialCapacity and Vector::uncheckedAppend for JSC's APIs

Modified: trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp (147510 => 147511)


--- trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp	2013-04-03 00:28:58 UTC (rev 147510)
+++ trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp	2013-04-03 00:34:31 UTC (rev 147511)
@@ -2937,7 +2937,7 @@
 
 double CodeBlock::optimizationThresholdScalingFactor()
 {
-    // This _expression_ arises from doing a least-squares fit of
+    // This _expression_ originally arose from doing a least-squares fit of
     //
     // F[x_] =: a * Sqrt[x + b] + Abs[c * x] + d
     //
@@ -2951,8 +2951,13 @@
     //  4000       5.5          (random large size, used to cause the function to converge to a shallow curve of some sort)
     // 10000       6.0          (similar to above)
     //
-    // I achieve the minimization using the following Mathematica code:
+    // Since then, as compile times have gone down and optimization value has gone up, we've
+    // tweaked the function to favor earlier compilation.
     //
+    // What follows is a complete description of how to reproduce the original coefficients:
+    //
+    // I achieved the minimization using the following Mathematica code:
+    //
     // MyFunctionTemplate[x_, a_, b_, c_, d_] := a*Sqrt[x + b] + Abs[c*x] + d
     //
     // samples = {{10, 0.9}, {200, 1}, {320, 1.2}, {1268, 5}, {4000, 5.5}, {10000, 6}}
@@ -2991,21 +2996,23 @@
     // the function turning over and going negative for large x) and I threw in a Sqrt
     // term because Sqrt represents my intution that the function should be more sensitive
     // to small changes in small values of x, but less sensitive when x gets large.
-    
+    //
     // Note that the current fit essentially eliminates the linear portion of the
     // _expression_ (c == 0.0).
+
     const double a = 0.061504;
     const double b = 1.02406;
     const double c = 0.0;
     const double d = 0.825914;
+    const double instructionRatio = 0.8;
     
-    double instructionCount = this->instructionCount();
+    double x = instructionCount() * instructionRatio;
     
-    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.
+    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.
     
-    double result = d + a * sqrt(instructionCount + b) + c * instructionCount;
+    double result = d + a * sqrt(x + b) + c * x;
 #if ENABLE(JIT_VERBOSE_OSR)
-    dataLog(*this, ": instruction count is ", instructionCount, ", scaling execution counter by ", result, " * ", codeTypeThresholdMultiplier(), "\n");
+    dataLog(*this, ": instruction count is ", instructionCount(), ", scaling execution counter by ", result, " * ", codeTypeThresholdMultiplier(), "\n");
 #endif
     return result * codeTypeThresholdMultiplier();
 }
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to