603851 - Make v8-crypto fast

Status: RESOLVED DUPLICATE of bug 768572

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

What I've discovered so far:

1. JM is only about 10% slower doing one run of the workload in shell. But our shell score is 20% slower--I'm guessing GC but I don't really know.

2. About 90% of the time is spent in the function |am3|. JM is also about 10% slower running that function, so that's probably the bulk of it. This function mostly just does a bunch of math, which normally would mean (a) JM would be about equal to V8 (instead of 10% slower) and (b) TM would be fastest of all (instead of a bunch slower than JM, as seen on AWFY).

3. The JM loss vs. V8 seems to be coming from the array reads. Our array read path probably has more guards, and it reads two words instead of one on x86/ARM. I don't know which is more important, but we can try to measure that.

4. The test also creates some arrays, which might be slowing us down. There we are bound by the allocator so we can't solve that in the near term.

5. Bill said he thought the TM loss was due to the oracle not noticing that certain things should be ints. |am3| seems designed to make sure everything stays as 29-bit ints, so I would assume everything is always an int here. When I tried the tracer on an |am3| microbenchmark, it was 25% faster than V8. So getting this to trace properly with all ints is probably the winning strategy.

Comment 1

[Till Schneidereit [:till]]

IM work for this is tracked elsewhere.

Filter on jm-cleanup.