802830 - Analyze boxing and unbox operations in benchmarks

Status: RESOLVED DUPLICATE of bug 1401624

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

SpiderMonkey is consistently slower on x64 than x86 for the V8 benchmark, and consistently faster for Kraken. Since the compilers are largely identical, our boxing format may be to blame. Encoding doubles is free, but boxing and unboxing strings and objects requires 2-3 instructions and sometimes large immediate moves.

We should get some data on how often various box and unbox operations are happening on Kraken and V8. Ideally we'd know how many box and unbox operations occur on each benchmark, broken down into objects, strings, doubles, and int32|bool.

It would also be beneficial to know how these break down between flowing from objects or dense arrays, since some JS engines create special packed array types to store only doubles.

Comment 1

[Luke Wagner [:luke]]

Indeed, we should consider changing the 64-bit boxing format if the data shows that is the problem; the old format was optimized for *ahem* LeaveTrace.  In particular, if we switched to what JSC/V8 do and bias for pointers, we could avoid unboxing costs on *both* objects and strings by distinguishing the two by setting the LSB and adding -1 to the offset of any load that consumes the payload.

Comment 2

[Till Schneidereit [:till]]

This seems like something worth investigating again. It's the kind of difference from other engines that is probably detrimental just by being a difference: if people optimize for the other engines' behavior, then we might get penalized even though in theory the trade-offs look reasonable.

Jandem, I have no idea how much effort this is. It's probably not something to usefully do under the QF umbrella, but perhaps soon after that?

Comment 3

[Jan de Mooij [:jandem]]

(In reply to Till Schneidereit [:till] from comment #2)
> Jandem, I have no idea how much effort this is. It's probably not something
> to usefully do under the QF umbrella, but perhaps soon after that?

It probably makes sense to investigate Luke's suggestion in comment 1. We should also check what JSC is doing on 64-bit.

Changing this is quite a lot of work though and it's not clear how much it would help non-micro-benchmark workloads like Speedometer. On the one hand, (un)boxing is something that shows up everywhere in JIT code and C++ code so it's worth getting right, on the other hand I think we still have bigger perf issues.

Definitely something I want to look into though, maybe later this year.

Comment 4

[Worcester12345]

(In reply to Jan de Mooij [:jandem] from comment #3)
...

Definitely something I want to look into though, maybe later this year.

What were your findings?

Comment 5

[Iain Ireland [:iain]]

We tried changing our boxing format to be object-biased in bug 1401624. As described in bug 1559072 comment 3, it didn't end up being a net win. We backed out the changes.