743403 - Compiled fannkuch benchmark 50x slower on IonMonkey

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Alon Zakai (:azakai)]

Attachment: fannkuch

Attached is fannkuch compiled to JS from C++.

js -m -n 10        1.160 seconds
js --ion -n 10    57.008 seconds

Comment 1

[Nicolas B. Pierron [:nbp]]

IONFLAGS=all output: http://people.mozilla.com/~npierron/fannkuch-10-ion.log.xz

My guess is that this performance issue is related to lack of support of bytecode (by order of appearance in the log file):
> [Abort] INCSLOT non-int/double lhs
> [Abort] aborted @ ./_build/fannkuch.js:241
> …
> [Abort] Unsupported opcode: lookupswitch (line 156)
> [Abort] aborted @ ./_build/fannkuch.js:156
> …
> [Abort] Unsupported opcode: newinit (line 454)
> [Abort] aborted @ ./_build/fannkuch.js:454
> …
> [Abort] Unsupported opcode: try (line 2423)
> [Abort] aborted @ ./_build/fannkuch.js:2423

I also remarked that we have more than 10000 MIR instructions and a lot of snapshots mostly containing huge sets of undefined/osr values.

Comment 2

[nemo]

http://arewefastyet.com/?machine=10&view=breakdown#ss-fannkuch

Seems fixed?
Ok, not quite up to JM+TI, but nowhere near 50x.
Also bug it depends on was fixed a while ago.

Comment 3

[Alon Zakai (:azakai)]

Compiled fannkuch has very different performance characteristics than the handwritten one on awfy, so that needs checking. I'm not on my usual machine that has ionmonkey builds right now but I'll check it as soon as I can.

Comment 4

[Alon Zakai (:azakai)]

So, with the new ionmonkey shell settings I am not sure what parameters to use. I want to compare -m -n to --ion -n like in comment 0, but the shell says that by default JM, TI and IM are all on? Not sure I understand how those work together, but these are results using my best guess for arguments:

-m -n --no-ion     1.120
--ion -n --no-jm  58.096

If the arguments are right then the slowdown is still about 50x.

Comment 5

[Hannes Verschore [:h4writer]]

The important comparison is:
./js:          3.4s
./js --no-ion: 3.5s

As this compares IM with the performance it gets shipped VS the JM performance. In this case IM is faster (or equals) JM.

The reason why --no-jm is slower, is because IM is slower in compiling code. Therefore JM is used as a fast compiler until code is very very hot, justifying the slower compilation phase resulting in faster execution code. When disabling JM, IM kicks in earlier and the slower compilation phase (and recompilations) probably hurt this benchmark so much:
./js --no-jm:   2m42.854s

Comment 6

[Jan de Mooij [:jandem]]

I get 750 ms and 808 ms with --no-ion, so closing this.