mimic the jsc shell function run() for latest sunspider

The Sunspider command-line tool changed in order to improve its accuracy:

http://trac.webkit.org/changeset/72842

In order to execute this benchmark out-of-the-box d8 should mimic the run() function in JavaScriptCore shell.

The first approach (patch set 2) adds the run() function only to the d8 shell.

The second approach adds a new extension for it (--expose_run) and also it creates a new context for each run() call

[vjaquez, 2011-03-29 15:50:31]

The Sunspider command-line tool changed in order to improve its accuracy:

http://trac.webkit.org/changeset/72842

In order to execute this benchmark out-of-the-box d8 should mimic the run()
function in JavaScriptCore shell.

This patch adds the run() function to the d8 shell.

[Mads Ager (chromium), 2011-04-01 20:40:21]

The run method of the webkit patch did more than this patch. It made sure that
the code is evaluated with a fresh global object. 

If we add a run method to our shell to be able to run SunSpider out of the box
we should do that as well. Also, I think we should add run to the shell sample
instead of to d8. Normally, we use the shell sample to run benchmarks and not
d8.

Note unrelated to this patch: I'd like to discourage people from using SunSpider
as a benchmark at all. It is irrelevant at this point. The benchmarks run for
only a couple of milliseconds and most of them make little sense. Let's use
better benchmarks. :)

[vjaquez, 2011-04-02 13:30:31]

On 2011/04/01 20:40:21, Mads Ager wrote:
> The run method of the webkit patch did more than this patch. It made sure that
> the code is evaluated with a fresh global object. 

Ok. I'll check it out.

> 
> If we add a run method to our shell to be able to run SunSpider out of the box
> we should do that as well. Also, I think we should add run to the shell sample
> instead of to d8. Normally, we use the shell sample to run benchmarks and not
> d8.

Ok. As I used OS::TimeCurrentMillis() and it is internal api, hence I assume
that the approach would be just as the --expose_gc flag, an extension.

> 
> Note unrelated to this patch: I'd like to discourage people from using
SunSpider
> as a benchmark at all. It is irrelevant at this point. The benchmarks run for
> only a couple of milliseconds and most of them make little sense. Let's use
> better benchmarks. :)

That makes sense. Also, kraken uses the old approach of sunspider:

https://hg.mozilla.org/projects/kraken/file/e119421cb325/resources/sunspider-...

[vjaquez, 2011-04-05 11:35:12]

On 2011/04/02 13:30:31, vjaquez wrote:
> On 2011/04/01 20:40:21, Mads Ager wrote:
> > If we add a run method to our shell to be able to run SunSpider out of the
box
> > we should do that as well. Also, I think we should add run to the shell
sample
> > instead of to d8. Normally, we use the shell sample to run benchmarks and
not
> > d8.
> 
> Ok. As I used OS::TimeCurrentMillis() and it is internal api, hence I assume
> that the approach would be just as the --expose_gc flag, an extension.
> 

The extension approach seems not to be right: I would mean duplicate code
(ReadFile() and ExecuteString()). I'll add it only in shell.cc then

[vjaquez, 2011-04-07 19:03:19]

Following the Mads' recommendations I moved the run() as an extension and
instantiates a new context for each function call.

But the patch expose an interesting behavior:

If I run sunspider on x64 I got an expected result:

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  561.4ms +/- 1.0%
--------------------------------------------

  3d:                    89.4ms +/- 3.2%
    cube:                26.1ms +/- 4.9%
    morph:               29.1ms +/- 1.4%
    raytrace:            34.2ms +/- 7.1%

  access:                48.9ms +/- 0.8%
    binary-trees:         6.2ms +/- 4.9%
    fannkuch:            18.6ms +/- 2.0%
    nbody:               15.1ms +/- 1.5%
    nsieve:               9.0ms +/- 0.0%

  bitops:                53.7ms +/- 1.7%
    3bit-bits-in-byte:    9.0ms +/- 5.3%
    bits-in-byte:        13.0ms +/- 0.0%
    bitwise-and:         20.2ms +/- 1.5%
    nsieve-bits:         11.5ms +/- 3.3%

  controlflow:            7.9ms +/- 2.9%
    recursive:            7.9ms +/- 2.9%

  crypto:                42.1ms +/- 1.3%
    aes:                 21.1ms +/- 2.5%
    md5:                 10.1ms +/- 4.0%
    sha1:                10.9ms +/- 2.1%

  date:                  74.2ms +/- 1.4%
    format-tofte:        29.2ms +/- 3.0%
    format-xparb:        45.0ms +/- 1.1%

  math:                  44.3ms +/- 1.7%
    cordic:               9.3ms +/- 3.7%
    partial-sums:        24.2ms +/- 1.9%
    spectral-norm:       10.8ms +/- 4.2%

  regexp:                26.7ms +/- 1.3%
    dna:                 26.7ms +/- 1.3%

  string:               174.2ms +/- 1.4%
    base64:              11.5ms +/- 5.3%
    fasta:               24.2ms +/- 2.7%
    tagcloud:            57.3ms +/- 1.7%
    unpack-code:         60.2ms +/- 1.8%
    validate-input:      21.0ms +/- 4.2%


*BUT* if I run the same on ARMv7 (Pandaboard) the story is different:

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  9663677970.0ms +/- 25.1%
--------------------------------------------

  3d:                   1932735525.2ms +/- 25.1%
    cube:               1932735282.3ms +/- 25.1%
    morph:                     114.9ms +/- 25.1%
    raytrace:                  128.0ms +/- 26.3%

  access:               1932735412.0ms +/- 25.1%
    binary-trees:               18.0ms +/- 25.2%
    fannkuch:                   89.7ms +/- 25.1%
    nbody:              1932735282.3ms +/- 25.1%
    nsieve:                     22.0ms +/- 25.2%

  bitops:                      138.0ms +/- 25.1%
    3bit-bits-in-byte:          18.8ms +/- 25.2%
    bits-in-byte:               24.2ms +/- 25.2%
    bitwise-and:                49.3ms +/- 25.2%
    nsieve-bits:                45.7ms +/- 25.1%

  controlflow:                  19.8ms +/- 25.1%
    recursive:                  19.8ms +/- 25.1%

  crypto:                      166.3ms +/- 25.3%
    aes:                        67.0ms +/- 26.0%
    md5:                        64.3ms +/- 25.1%
    sha1:                       35.0ms +/- 25.1%

  date:                        250.6ms +/- 25.3%
    format-tofte:              102.4ms +/- 25.2%
    format-xparb:              148.2ms +/- 25.6%

  math:                 1932735334.1ms +/- 25.1%
    cordic:                     31.4ms +/- 25.1%
    partial-sums:       1932735282.3ms +/- 25.1%
    spectral-norm:              20.4ms +/- 25.5%

  regexp:                      133.0ms +/- 25.1%
    dna:                       133.0ms +/- 25.1%

  string:               3865470991.0ms +/- 25.1%
    base64:             1932735282.3ms +/- 25.1%
    fasta:                      62.9ms +/- 25.4%
    tagcloud:                  163.2ms +/- 25.3%
    unpack-code:               200.3ms +/- 25.1%
    validate-input:     1932735282.3ms +/- 25.1%


As you can observe, several tests seem to smash the stack, modifying the _start
variable.

Perhaps this is related with https://code.google.com/p/v8/issues/detail?id=1305
which I also observe but only on sunspider, not in kraken

Thanks