523792 - inlining the fast path of GC thing allocation

Status: RESOLVED DUPLICATE of bug 558861

(Core :: JavaScript Engine, enhancement)

Description

[Igor Bukanov]

With changes from the bug 522867 the fast path of the GC allocator contains the single "if" that checks for a non-empty free list. As such it should be straightforward to inline it without much code bloat.

Comment 1

[Igor Bukanov]

Attachment: v1

The patch is a straightforward implementation of the inlining idea. But the SS benchmark shows no difference with patch on 64 bit Linux:



TEST                   COMPARISON            FROM                 TO             DETAILS

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

** TOTAL **:           -                 769.7ms +/- 1.0%   768.6ms +/- 0.9% 

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

  3d:                  ??                147.0ms +/- 3.5%   149.2ms +/- 3.1%     not conclusive: might be *1.015x as slow*
    cube:              ??                 44.1ms +/- 3.7%    45.1ms +/- 3.4%     not conclusive: might be *1.024x as slow*
    morph:             -                  34.8ms +/- 3.8%    34.7ms +/- 3.2% 
    raytrace:          ??                 68.1ms +/- 3.4%    69.5ms +/- 2.9%     not conclusive: might be *1.020x as slow*

  access:              ??                109.9ms +/- 2.8%   112.1ms +/- 2.3%     not conclusive: might be *1.020x as slow*
    binary-trees:      ??                 28.6ms +/- 4.0%    29.3ms +/- 3.3%     not conclusive: might be *1.025x as slow*
    fannkuch:          *1.058x as slow*   51.7ms +/- 3.4%    54.6ms +/- 2.7%     significant
    nbody:             1.072x as fast     18.3ms +/- 3.6%    17.1ms +/- 3.6%     significant
    nsieve:            -                  11.4ms +/- 3.6%    11.1ms +/- 3.2% 

  bitops:              -                  32.0ms +/- 2.8%    31.0ms +/- 2.5% 
    3bit-bits-in-byte: ??                  1.3ms +/- 10.1%     1.3ms +/- 10.2%     not conclusive: might be *1.047x as slow*
    bits-in-byte:      ??                 10.1ms +/- 3.5%    10.1ms +/- 3.5%     not conclusive: might be *1.002x as slow*
    bitwise-and:       -                   2.2ms +/- 6.3%     2.1ms +/- 5.8% 
    nsieve-bits:       1.058x as fast     18.5ms +/- 2.8%    17.4ms +/- 2.2%     significant

  controlflow:         -                   7.3ms +/- 2.6%     7.3ms +/- 2.1% 
    recursive:         -                   7.3ms +/- 2.6%     7.3ms +/- 2.1% 

  crypto:              -                  45.3ms +/- 1.6%    44.6ms +/- 1.6% 
    aes:               -                  25.7ms +/- 1.9%    25.0ms +/- 2.6% 
    md5:               -                  13.0ms +/- 2.0%    12.9ms +/- 1.5% 
    sha1:              ??                  6.6ms +/- 2.3%     6.7ms +/- 2.3%     not conclusive: might be *1.015x as slow*

  date:                -                 106.6ms +/- 0.5%   106.3ms +/- 0.3% 
    format-tofte:      -                  58.9ms +/- 0.8%    58.8ms +/- 0.3% 
    format-xparb:      -                  47.7ms +/- 0.5%    47.5ms +/- 0.5% 

  math:                -                  33.5ms +/- 0.7%    33.3ms +/- 0.7% 
    cordic:            1.019x as fast     12.6ms +/- 1.2%    12.4ms +/- 1.3%     significant
    partial-sums:      ??                 15.5ms +/- 1.0%    15.7ms +/- 1.0%     not conclusive: might be *1.012x as slow*
    spectral-norm:     -                   5.3ms +/- 2.5%     5.3ms +/- 2.4% 

  regexp:              ??                 52.5ms +/- 0.4%    52.5ms +/- 0.4%     not conclusive: might be *1.001x as slow*
    dna:               ??                 52.5ms +/- 0.4%    52.5ms +/- 0.4%     not conclusive: might be *1.001x as slow*

  string:              1.015x as fast    235.6ms +/- 0.3%   232.2ms +/- 0.4%     significant
    base64:            1.033x as fast     10.8ms +/- 1.5%    10.4ms +/- 1.4%     significant
    fasta:             ??                 47.8ms +/- 0.4%    47.9ms +/- 0.4%     not conclusive: might be *1.002x as slow*
    tagcloud:          1.015x as fast     76.9ms +/- 0.2%    75.7ms +/- 0.2%     significant
    unpack-code:       1.020x as fast     82.3ms +/- 0.6%    80.7ms +/- 1.0%     significant
    validate-input:    1.024x as fast     17.8ms +/- 0.6%    17.4ms +/- 0.8%     significant


I will investigate why fannkuch is almost 6% slower with the patch.

Comment 2

[Nicholas Nethercote [inactive]]

My experience is that fannkuch is pretty noisy.

Comment 3

[Igor Bukanov]

This was resolved as a part of the bug 558861