Title: [201836] trunk
Revision
201836
Author
commit-qu...@webkit.org
Date
2016-06-08 15:22:49 -0700 (Wed, 08 Jun 2016)

Log Message

[JSC] Change some parameters based on a random search
https://bugs.webkit.org/show_bug.cgi?id=158514

Source/_javascript_Core:

Patch by Benjamin Poulain <bpoul...@apple.com> on 2016-06-08
Reviewed by Filip Pizlo.

Over the weekend, I left an iMac running the JSC benchmarks
while changing a bunch of parameters.

The parameters were changed randomly, with a random deviation
from the original value.
To converge toward good values, the range was subject
to exponential annealing over time.

The values in this patch is the best outcome my iMac could
find over the weekend. It is about 1% better on the Haswell
machines I tested.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::optimizationThresholdScalingFactor):
* runtime/Options.h:

Tools:

Patch by Benjamin Poulain <benja...@webkit.org> on 2016-06-08
Reviewed by Filip Pizlo.

* Scripts/run-jsc-stress-tests:

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (201835 => 201836)


--- trunk/Source/_javascript_Core/ChangeLog	2016-06-08 22:14:55 UTC (rev 201835)
+++ trunk/Source/_javascript_Core/ChangeLog	2016-06-08 22:22:49 UTC (rev 201836)
@@ -1,3 +1,26 @@
+2016-06-08  Benjamin Poulain  <bpoul...@apple.com>
+
+        [JSC] Change some parameters based on a random search
+        https://bugs.webkit.org/show_bug.cgi?id=158514
+
+        Reviewed by Filip Pizlo.
+
+        Over the weekend, I left an iMac running the JSC benchmarks
+        while changing a bunch of parameters.
+
+        The parameters were changed randomly, with a random deviation
+        from the original value.
+        To converge toward good values, the range was subject
+        to exponential annealing over time.
+
+        The values in this patch is the best outcome my iMac could
+        find over the weekend. It is about 1% better on the Haswell
+        machines I tested.
+
+        * bytecode/CodeBlock.cpp:
+        (JSC::CodeBlock::optimizationThresholdScalingFactor):
+        * runtime/Options.h:
+
 2016-06-08  Gavin Barraclough  <barraclo...@apple.com>
 
         Remove removeDirect

Modified: trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp (201835 => 201836)


--- trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp	2016-06-08 22:14:55 UTC (rev 201835)
+++ trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp	2016-06-08 22:22:49 UTC (rev 201836)
@@ -3616,68 +3616,17 @@
 
 double CodeBlock::optimizationThresholdScalingFactor()
 {
-    // This _expression_ arises from doing a least-squares fit of
+    // We want a good threshold based on the instruction count.
+    // Here, we are trying to optimize the following formula:
+    //     F[x_] =: a * Sqrt[x + b] + Abs[c * x] + d
     //
-    // F[x_] =: a * Sqrt[x + b] + Abs[c * x] + d
-    //
-    // against the data points:
-    //
-    //    x       F[x_]
-    //    10       0.9          (smallest reasonable code block)
-    //   200       1.0          (typical small-ish code block)
-    //   320       1.2          (something I saw in 3d-cube that I wanted to optimize)
-    //  1268       5.0          (something I saw in 3d-cube that I didn't want to optimize)
-    //  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:
-    //
-    // 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}}
-    //
-    // solution = 
-    //     Minimize[Plus @@ ((MyFunctionTemplate[#[[1]], a, b, c, d] - #[[2]])^2 & /@ samples),
-    //         {a, b, c, d}][[2]]
-    //
-    // And the code below (to initialize a, b, c, d) is generated by:
-    //
-    // Print["const double " <> ToString[#[[1]]] <> " = " <>
-    //     If[#[[2]] < 0.00001, "0.0", ToString[#[[2]]]] <> ";"] & /@ solution
-    //
-    // We've long known the following to be true:
-    // - Small code blocks are cheap to optimize and so we should do it sooner rather
-    //   than later.
-    // - Large code blocks are expensive to optimize and so we should postpone doing so,
-    //   and sometimes have a large enough threshold that we never optimize them.
-    // - The difference in cost is not totally linear because (a) just invoking the
-    //   DFG incurs some base cost and (b) for large code blocks there is enough slop
-    //   in the correlation between instruction count and the actual compilation cost
-    //   that for those large blocks, the instruction count should not have a strong
-    //   influence on our threshold.
-    //
-    // I knew the goals but I didn't know how to achieve them; so I picked an interesting
-    // example where the heuristics were right (code block in 3d-cube with instruction
-    // count 320, which got compiled early as it should have been) and one where they were
-    // totally wrong (code block in 3d-cube with instruction count 1268, which was expensive
-    // to compile and didn't run often enough to warrant compilation in my opinion), and
-    // then threw in additional data points that represented my own guess of what our
-    // heuristics should do for some round-numbered examples.
-    //
-    // The _expression_ to which I decided to fit the data arose because I started with an
-    // affine function, and then did two things: put the linear part in an Abs to ensure
-    // that the fit didn't end up choosing a negative value of c (which would result in
-    // 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.
+    // The parameters were chosen by testing random values
+    // between 1 and 2 and keeping the best combination.
+    const double a = Options::optimizationThresholdScalingFactorA();
+    const double b = Options::optimizationThresholdScalingFactorB();
+    const double c = Options::optimizationThresholdScalingFactorC();
+    const double d = Options::optimizationThresholdScalingFactorD();
     
-    // 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;
-    
     double instructionCount = this->instructionCount();
     
     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.

Modified: trunk/Source/_javascript_Core/runtime/Options.h (201835 => 201836)


--- trunk/Source/_javascript_Core/runtime/Options.h	2016-06-08 22:14:55 UTC (rev 201835)
+++ trunk/Source/_javascript_Core/runtime/Options.h	2016-06-08 22:22:49 UTC (rev 201836)
@@ -253,23 +253,28 @@
     \
     v(double, jitPolicyScale, 1.0, Normal, "scale JIT thresholds to this specified ratio between 0.0 (compile ASAP) and 1.0 (compile like normal).") \
     v(bool, forceEagerCompilation, false, Normal, nullptr) \
-    v(int32, thresholdForJITAfterWarmUp, 500, Normal, nullptr) \
-    v(int32, thresholdForJITSoon, 100, Normal, nullptr) \
+    v(int32, thresholdForJITAfterWarmUp, 373, Normal, nullptr) \
+    v(int32, thresholdForJITSoon, 169, Normal, nullptr) \
     \
-    v(int32, thresholdForOptimizeAfterWarmUp, 1000, Normal, nullptr) \
-    v(int32, thresholdForOptimizeAfterLongWarmUp, 1000, Normal, nullptr) \
-    v(int32, thresholdForOptimizeSoon, 1000, Normal, nullptr) \
-    v(int32, executionCounterIncrementForLoop, 1, Normal, nullptr) \
-    v(int32, executionCounterIncrementForEntry, 15, Normal, nullptr) \
+    v(int32, thresholdForOptimizeAfterWarmUp, 511, Normal, nullptr) \
+    v(int32, thresholdForOptimizeAfterLongWarmUp, 885, Normal, nullptr) \
+    v(int32, thresholdForOptimizeSoon, 853, Normal, nullptr) \
+    v(int32, executionCounterIncrementForLoop, 2, Normal, nullptr) \
+    v(int32, executionCounterIncrementForEntry, 28, Normal, nullptr) \
     \
-    v(int32, thresholdForFTLOptimizeAfterWarmUp, 100000, Normal, nullptr) \
-    v(int32, thresholdForFTLOptimizeSoon, 1000, Normal, nullptr) \
-    v(int32, ftlTierUpCounterIncrementForLoop, 1, Normal, nullptr) \
-    v(int32, ftlTierUpCounterIncrementForReturn, 15, Normal, nullptr) \
+    v(int32, thresholdForFTLOptimizeAfterWarmUp, 99566, Normal, nullptr) \
+    v(int32, thresholdForFTLOptimizeSoon, 1566, Normal, nullptr) \
+    v(int32, ftlTierUpCounterIncrementForLoop, 6, Normal, nullptr) \
+    v(int32, ftlTierUpCounterIncrementForReturn, 13, Normal, nullptr) \
     v(unsigned, ftlOSREntryFailureCountForReoptimization, 15, Normal, nullptr) \
     v(unsigned, ftlOSREntryRetryThreshold, 100, Normal, nullptr) \
     \
-    v(int32, evalThresholdMultiplier, 10, Normal, nullptr) \
+    v(double, optimizationThresholdScalingFactorA, 0.1785461740514816, Normal, nullptr) \
+    v(double, optimizationThresholdScalingFactorB, 1.2691392484494950, Normal, nullptr) \
+    v(double, optimizationThresholdScalingFactorC, 0.0003675505121227, Normal, nullptr) \
+    v(double, optimizationThresholdScalingFactorD, 1.5838284192987762, Normal, nullptr) \
+    \
+    v(int32, evalThresholdMultiplier, 8, Normal, nullptr) \
     v(unsigned, maximumEvalCacheableSourceLength, 256, Normal, nullptr) \
     \
     v(bool, randomizeExecutionCountsBetweenCheckpoints, false, Normal, nullptr) \

Modified: trunk/Tools/ChangeLog (201835 => 201836)


--- trunk/Tools/ChangeLog	2016-06-08 22:14:55 UTC (rev 201835)
+++ trunk/Tools/ChangeLog	2016-06-08 22:22:49 UTC (rev 201836)
@@ -1,3 +1,12 @@
+2016-06-08  Benjamin Poulain  <benja...@webkit.org>
+
+        [JSC] Change some parameters based on a random search
+        https://bugs.webkit.org/show_bug.cgi?id=158514
+
+        Reviewed by Filip Pizlo.
+
+        * Scripts/run-jsc-stress-tests:
+
 2016-06-08  Aakash Jain  <aakash_j...@apple.com>
 
         tests fail if display sleeps while run-webkit-tests is running

Modified: trunk/Tools/Scripts/run-jsc-stress-tests (201835 => 201836)


--- trunk/Tools/Scripts/run-jsc-stress-tests	2016-06-08 22:14:55 UTC (rev 201835)
+++ trunk/Tools/Scripts/run-jsc-stress-tests	2016-06-08 22:22:49 UTC (rev 201836)
@@ -428,7 +428,7 @@
 
 BASE_OPTIONS = ["--useFTLJIT=false", "--useFunctionDotArguments=true"]
 EAGER_OPTIONS = ["--thresholdForJITAfterWarmUp=10", "--thresholdForJITSoon=10", "--thresholdForOptimizeAfterWarmUp=20", "--thresholdForOptimizeAfterLongWarmUp=20", "--thresholdForOptimizeSoon=20", "--thresholdForFTLOptimizeAfterWarmUp=20", "--thresholdForFTLOptimizeSoon=20", "--maximumEvalCacheableSourceLength=150000"]
-NO_CJIT_OPTIONS = ["--useConcurrentJIT=false", "--thresholdForJITAfterWarmUp=100"]
+NO_CJIT_OPTIONS = ["--useConcurrentJIT=false", "--thresholdForJITAfterWarmUp=100", "--thresholdForJITSoon=100", "--thresholdForOptimizeAfterWarmUp=1000", "--thresholdForOptimizeAfterLongWarmUp=1000", "--thresholdForOptimizeSoon=1000", "--executionCounterIncrementForLoop=1", "--executionCounterIncrementForEntry=15", "--thresholdForFTLOptimizeAfterWarmUp=100000", "--thresholdForFTLOptimizeSoon=1000", "--ftlTierUpCounterIncrementForLoop=1", "--ftlTierUpCounterIncrementForReturn=15", "--evalThresholdMultiplier=10", "--optimizationThresholdScalingFactorA=0.061504", "--optimizationThresholdScalingFactorB=1.02406", "--optimizationThresholdScalingFactorC=0.0", "--optimizationThresholdScalingFactorD=0.825914"]
 FTL_OPTIONS = ["--useFTLJIT=true"]
 
 $runlist = []
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to