Closed Bug 768557 Opened 10 years ago Closed 10 years ago

IonMonkey: dlmalloc is slow

Categories

(Core :: JavaScript Engine, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mjrosenb, Unassigned)

Details

Attachments

(1 file)

I noticed that dlmalloc was rather slow, and upon tracing it, it compiled two functions with IonMonkey, main and a small helper function.  Unfortunately, main calls malloc and free several thousand times, and neither of them are small enough to compile with IM, so we end up bouncing between Ion code and JM code, slowing us down immensely.
The attached patch keeps track of how many times we attempt to call an uncompilable function, and when the appropriate limit is reached, the caller is invalidated and marked as uncompilable.
Attachment #636783 - Flags: review?(jdemooij)
Oh right, some stats!
This is the current setup vs. the new setup:
nothing to write home about.
TEST                              COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:                      1.009x as fast    14303.1ms +/- 0.4%   14179.7ms +/- 0.2%     significant

=============================================================================
  emscripten:                     1.030x as fast     6670.1ms +/- 0.6%    6478.7ms +/- 0.3%     significant
    copy:                         -                    52.4ms +/- 1.3%      51.6ms +/- 1.2% 
    corrections:                  -                   264.3ms +/- 0.8%     262.2ms +/- 0.6% 
    dlmalloc:                     1.43x as fast       252.9ms +/- 1.7%     176.4ms +/- 2.2%     significant
    fannkuch:                     *1.011x as slow*   1110.7ms +/- 0.6%    1123.0ms +/- 0.5%     significant
    fasta_float:                  *1.012x as slow*    407.5ms +/- 0.9%     412.3ms +/- 0.5%     significant
    memops:                       1.052x as fast     2315.5ms +/- 0.9%    2201.5ms +/- 0.4%     significant
    primes:                       -                  1060.1ms +/- 0.9%    1058.5ms +/- 0.4% 
    skinning:                     -                  1206.7ms +/- 0.7%    1193.2ms +/- 1.0% 


however, if we take a look at the new setup with and without IM:
TEST                              COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:                      *1.053x as slow*  13468.6ms +/- 0.4%   14179.7ms +/- 0.2%     significant

=============================================================================

  emscripten:                     1.098x as fast     7113.3ms +/- 0.5%    6478.7ms +/- 0.3%     significant
    copy:                         1.85x as fast        95.5ms +/- 1.6%      51.6ms +/- 1.2%     significant
    corrections:                  2.33x as fast       609.9ms +/- 1.0%     262.2ms +/- 0.6%     significant
    dlmalloc:                     *1.035x as slow*    170.5ms +/- 2.0%     176.4ms +/- 2.2%     significant
    fannkuch:                     ??                 1109.2ms +/- 1.4%    1123.0ms +/- 0.5%     not conclusive: might be *1.012x as slow*
    fasta_float:                  1.46x as fast       600.4ms +/- 1.1%     412.3ms +/- 0.5%     significant
    memops:                       1.025x as fast     2257.4ms +/- 0.8%    2201.5ms +/- 0.4%     significant
    primes:                       -                  1064.5ms +/- 0.5%    1058.5ms +/- 0.4% 
    skinning:                     -                  1205.9ms +/- 0.8%    1193.2ms +/- 1.0% 

v8 sunspider and kraken remain unchanged.
Comment on attachment 636783 [details] [diff] [review]
/home/mrosenberg/patches/debounceIM-r0.patch

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

Looks good, r=me with nits addressed.

There's an unrelated MAX_SCRIPT_SIZE change but it looks like it just undoes another patch.

::: js/src/ion/Ion.h
@@ +139,5 @@
>  
> +    // If a function has attempted to make this many calls to
> +    // functions that are marked "uncompileable", then
> +    // stop running this function in IonMonkey. (default 512)
> +    uint32 bounceLimit;

Nit: "slowCallLimit" or something may be more descriptive

::: js/src/ion/VMFunctions.cpp
@@ +69,5 @@
> +    // hitting functions that are uncompilable.
> +
> +    if (fun->script()->ion == ION_DISABLED_SCRIPT) {
> +        if (++cx->stack.currentScript()->ion->bounceCount >= js_IonOptions.bounceLimit) {
> +            JSScript *script = cx->stack.currentScript();

Nit: if we move this before the inner "if" we can s/cx->stack.currentScript()/script in the condition.

@@ +71,5 @@
> +    if (fun->script()->ion == ION_DISABLED_SCRIPT) {
> +        if (++cx->stack.currentScript()->ion->bounceCount >= js_IonOptions.bounceLimit) {
> +            JSScript *script = cx->stack.currentScript();
> +            Vector<types::RecompileInfo> scripts(cx);
> +            if (!scripts.append(types::RecompileInfo(script)), false)

Remove the ", false" at the end.
Attachment #636783 - Flags: review?(jdemooij) → review+
landed: http://hg.mozilla.org/projects/ionmonkey/rev/d3d8dcc50da0
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.