590161 - JM: make strict equality ops faster

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

JM has fast paths for === and !== if one side is true/false/null/undefined. Many benchmarks/scripts use these operators to compare integer values. Adding fast paths will help JSNES, sjcl and others quite a lot.

Comment 1

[Jan de Mooij [:jandem]]

These operators are rare in V8/SS (except earley-boyer), so blocking JaegerPunyWins. But wins on other benchmarks can be much bigger.

Another thing is fusing opcodes with IFEQ/IFNE. I'm not sure how to do all this without adding tons of if's, so leaving this to someone else.

Comment 2

[Sean Stangl [:sstangl]]

I wrote a patch for this in bug 578528. It was never reviewed, and languished there. The only odd thing with writing a fastpath for these ops is that the stub call's return value should be inlined, not written to the stack -- doing so is measurably slower.

Writing int32 fastpaths for these ops gives JSNES about a 10 FPS increase on my machine.

Comment 3

[Jan de Mooij [:jandem]]

(In reply to comment #2)
> Writing int32 fastpaths for these ops gives JSNES about a 10 FPS increase on my
> machine.
That's great, 10 FPS is more than I expected.

We can mark this as duplicate or keep it open for the op-fusing and (maybe) other fast paths, both is fine with me.

Comment 4

[Jan de Mooij [:jandem]]

Strict equality is still slower than non-strict equality. For this benchmark:
-----
function f(x) {
    var c = 0;
    for(var i=0; i<10000000; i++) {
	var a = x | 0;
	if (a === 10) { c++; }
    }
}
var t0 = new Date;
f(10);
print(new Date - t0);
-----
For ==:    JM: 46 ms, TM: 37 ms, V8: 46 ms.
For ===: JM: 55 ms, TM: 34 ms, V8: 46 ms. 

Strict comparison is still 20% slower; we should port some optimizations to ===. Bug 603715 wil make strict object comparisons fast, this bug is about optimizing the current int === int code.

Comment 5

[Jan de Mooij [:jandem]]

Attachment: Patch v1

This makes JSOP_STRICT{EQ,NE} more like JSOP_EQ etc. This patch passes trace-tests and makes === as fast as == for the micro-benchmark in comment 4.

I still have to do some cleanup and double-check everything. The op fusing adds a bunch of if-statements to the compiler and I'll try to move the constant null/bool/.. cases to their own functions.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

	==	===
Interp	916	956
TM	903	954
JM	71	96
JM+TI	28	27
d8	25	25

Looks like JM+TI handles both cases fine. jandem, is there more to do here or is this WORKSFORME?

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Ryan VanderMeulen from comment #6)
> 
> Looks like JM+TI handles both cases fine. jandem, is there more to do here
> or is this WORKSFORME?

Yeah works fine with JM+TI and Ion.