Jan de Mooij [:jandem] Assignee
	Description • 14 years ago

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.

	Jan de Mooij [:jandem] Assignee
	Comment 1 • 14 years ago

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.

	Sean Stangl [:sstangl]
	Comment 2 • 14 years ago

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.

	Jan de Mooij [:jandem] Assignee
	Comment 3 • 14 years ago

(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.

	Jan de Mooij [:jandem] Assignee
	Comment 4 • 14 years ago

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.

	Jan de Mooij [:jandem] Assignee
	Comment 5 • 14 years ago

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.

	Ryan VanderMeulen [:RyanVM]
	Comment 6 • 13 years ago

	==	===
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?

	Jan de Mooij [:jandem] Assignee
	Comment 7 • 12 years ago

(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.