Closed Bug 802830 Opened 9 years ago Closed 4 months ago

Analyze boxing and unbox operations in benchmarks

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1401624

People

(Reporter: dvander, Unassigned)

References

(Blocks 1 open bug)

Details

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.
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.
Assignee: general → nobody
Assignee: nobody → evilpies
Assignee: evilpies → nobody
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?
Flags: needinfo?(jdemooij)
(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.
Blocks: jsperf
Flags: needinfo?(jdemooij)

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

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.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1401624
You need to log in before you can comment on or make changes to this bug.