783143 - IonMonkey: Fix JSNES performance

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Sean Stangl [:sstangl]]

The JSNES benchmark in the URL underneath suffers a ~3x regression with an opt x86_64 IonMonkey-enabled browser.

Firefox 17: 731ms
Firefox IM: 2343ms
Chrome 21:  627ms

Repo containing benchmark: https://github.com/bfirsh/jsnes/blob/master/test/benchmark.html

Comment 1

[Sean Stangl [:sstangl]]

Attachment: JSNES shell benchmark

Modified JSNES to run in the shell:

IonMonkey:   421.90ms (per frame)
IM --no-ion: 188.80ms
V8:           30.80ms

File to run is test/shell-bench.js.

Comment 2

[Sean Stangl [:sstangl]]

(In reply to Sean Stangl from comment #1)
> Modified JSNES to run in the shell:

*Actually* using opt builds this time, the results are:
IonMonkey:   35.50ms
IM --no-ion: 45.10ms
V8:          30.80ms

So that benchmark isn't hitting the same slowness as in the browser benchmark.

Comment 3

[Sean Stangl [:sstangl]]

Shell benchmark differs from browser because ROM memory is being loaded incorrectly -- the browser uses atob(rom), while the shell uses Base64.decode(rom) with a special Base64 library, as called in test/benchmark.js. Need to fix the Base64 library to match browser behavior.

Comment 4

[Sean Stangl [:sstangl]]

Attachment: JSNES shell benchmark [v2]

Fixed benchmark: now decodes the croom ROM correctly. Run via test/shell-bench.js. Some interesting data follow.

If we just look at the performance output reported by aggregating a number of runs, we see the following, which looks quite bad for IonMonkey:

> v8: 569ms
> JM: 774ms
> IM: 954ms

On the other hand, if we look at the result of each individual run before they are averaged, we see the following interesting performance characteristics:

> _____v8_____   _____JM_____   _____IM_____
> warmup: 645    warmup: 714    warmup: 759
> warmup: 514    warmup: 711    warmup: 2150
> warmup: 607    warmup: 897    warmup: 1572
> result: 577    result: 1043   result: 666
> result: 580    result: 1258   result: 2372
> result: 569    result: 726    result: 2408
> result: 569    result: 691    result: 693
> result: 572    result: 694    result: 567
> result: 567    result: 683    result: 565
> result: 565    result: 683    result: 553
> result: 565    result: 685    result: 553
> result: 564    result: 658    result: 551
> result: 568    result: 620    result: 618

Which shows that IM is actually *faster* than v8, except for some hiccups. The usual culprits are compilation overhead and GC; the former seems most culpable.

Comment 5

[Sean Stangl [:sstangl]]

Attachment: Log: Compilation Overhead

Log of compilation overhead on opt x86_64. Times in microseconds.

The problem is visibly the function clockFrameCounter() at ppu.js:289, which inlines 3 other functions, has a compilation time of about 3ms. Based on the number of times it's compiled, the total compilation overhead is ~4.3 seconds.

> [sstangl@mozdesk test]$ ~/opt64/js ./shell-bench.js | grep -c ":289"
> 1442

Comment 6

[Sean Stangl [:sstangl]]

JSNES is slightly less than twice as slow now on x86, probably from BC replacing JM:

> Average of 10 runs: 996.40ms.

v8 in the meantime has improved performance:

> Average of 10 runs: 459.50ms.

Comment 7

[Sean Stangl [:sstangl]]

Never mind: we're awesome!
> Average of 10 runs: 408.80ms.

Passing --ion-parallel-compile=on is necessary for the main emulation function to compile due to its script size.