836466 - BaselineCompiler: Tweak usesBeforeIonCompile for Baseline

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Kannan Vijayan [:djvj]]

Testing Ion+Baseline vs Ion+JM is difficult because  runniong ion with --no-jm causes the usecount limits for ion compilation to drop really low.  This causes more recompiles and bailouts when testing Ion+Baseline with --no-jm.

Given that the fallback cost for bailing from Ion is much lower when it's backed by baseline, we can probably afford to compile with Ion slightly more eagerly under baseline than with jm.

I'm going to start off with an initial useCount limit of 1024 for entering Ion from baseline, as opposed to the useCount of 10240 currently used for entering Ion when JM is enabled.

Comment 1

[Kannan Vijayan [:djvj]]

Attachment: Tune use count

With this in, we can start seeing some nice initial wins compard with Ion+JM:
    fannkuch:          1.138x as fast      7.1ms +/- 0.3%     6.2ms +/- 0.2%     significant
    3bit-bits-in-byte: 1.031x as fast      1.4ms +/- 0.4%     1.4ms +/- 0.3%     significant
    bitwise-and:       1.011x as fast      2.7ms +/- 0.3%     2.7ms +/- 0.2%     significant
    spectral-norm:     1.24x as fast       3.1ms +/- 0.3%     2.5ms +/- 0.1%     significant

(Note: the JM numbers are with the old 10240 useCountBeforeIonCompile.  Decreasing that number for Ion+JM leads to even worse numbers)

Comment 2

[Jan de Mooij [:jandem]]

Comment on attachment 708381 [details] [diff] [review]
Tune use count

Review of attachment 708381 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the comment below addressed.

::: js/src/ion/Ion.h
@@ +91,1 @@
>      uint32_t usesBeforeCompile;

This patch does not change the actual usesBeforeCompile value. I think we should revert this change and not lower the threshold until we really have to - the main risks with Ion-compiling more are analysis/compilation time (we don't do parallel compilation everywhere) and memory usage (especially on mobile).

Comment 3

[Kannan Vijayan [:djvj]]

Gak, I forgot to qref before taking the qdiff :)

Comment 4

[Kannan Vijayan [:djvj]]

Ok, leaving the useCount as is, and just leaving in the change where we don't use the useCountBeforeIonCompileNoJaeger (40) if --no-jm is passed but baseline is still enabled.

https://hg.mozilla.org/projects/ionmonkey/rev/e0f89562af69

Comment 5

[Brian Hackett [Laid off!]]

(In reply to Jan de Mooij [:jandem] from comment #2)
> This patch does not change the actual usesBeforeCompile value. I think we
> should revert this change and not lower the threshold until we really have
> to - the main risks with Ion-compiling more are analysis/compilation time
> (we don't do parallel compilation everywhere) and memory usage (especially
> on mobile).

I think the use count threshold needs to be lowered.  I experimented some with SS and use count thresholds, and see the behavior below.  All numbers are for threadsafe builds, two cores, x86/darwin.

With the current threshold, 10240:

trunk: 281.4
trunk --ion-parallel-compile=on: 271.6

baseline: 334.9
baseline --ion-parallel-compile=on: 341.6

With a threshold of 1000:

baseline: 300.8
baseline --ion-parallel-compile=on: 280.9

Lowering the threshold improves baseline performance greatly, whether parallel compilation is used or not.  When parallel compilation is used, performance is only 3.4% slower with baseline than on trunk.

Trying to close the 26% performance gap that exists with a use count of 10240 seems insurmountable.  There aren't that many caching opportunities left for baseline, and improving the efficiency of the caches themselves would require rearchitecting the caches and potentially using more memory.  For memory consumption, it would be far better to try to minimize baseline memory usage and just more readily Ion compile code that gets hot.

In bug 678037 comment 33 I measured how much code gets warm or hot on a typical web workload.  Out of all script data, 37% is executed at least once, 7.8% is executed at least 10 times (potential threshold for baseline compilation), and 0.03% (!!) is executed at least 1000 times.  I don't know what the difference is between 1000 and 10000 times, but it's clear that on normal workloads the amount of code that will be Ion compiled with a 1000 use count threshold is extremely small.

Comment 6

[Brian Hackett [Laid off!]]

Attachment: patch

Oh, I also tested SS a bit with lower use count thresholds.  The best performance I got was 275ms with a threshold of 500 and parallel compilation, but this increased the time without parallel compilation to 320ms.  So 1000 seems a reasonable default, but there is still some room for improvement with future tweaking.

Comment 7

[Jan de Mooij [:jandem]]

Comment on attachment 714948 [details] [diff] [review]
patch

Review of attachment 714948 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the benchmark/memory measurements, seems reasonable.

Comment 8

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/projects/ionmonkey/rev/1c8552cc6ec4