Fix: Regression in benchmarks JetStream, ARES, speedometer #1691#1695
Fix: Regression in benchmarks JetStream, ARES, speedometer #1691#1695justinmichaud wants to merge 1 commit into
Conversation
| finish(dst.withOffset(TagOffset)); | ||
| // CJIT is only enabled when LPAE is enabled (such as for armv8l). In this case, | ||
| // 64-bit aligned stores are atomic: https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Application-Level-Memory-Model/Memory-types-and-attributes-and-the-memory-order-model/Atomicity-in-the-ARM-architecture | ||
| // > In an implementation that includes the Large Physical Address Extension, LDRD and STRD accesses to 64-bit aligned locations are 64-bit single-copy atomic as seen by translation table walks and accesses to translation tables. |
There was a problem hiding this comment.
FWIW, I think the part we want to quote here is
The system designer must ensure that all writable memory locations that might be used to hold translations, such as bulk SDRAM, can be accessed with 64-bit single-copy atomicity.
(later in the same document)
| }); | ||
| } | ||
| } | ||
|
|
|
Looks great to me. |
justinmichaud
force-pushed
the
eng/2.46-perf-fixes
branch
from
93f3188 to
d00c8c1
Compare
…mForEmbedded#1691 Reviewed by aoikonomopoulos. This patch makes some simple fixes to improve 32-bit performance on 2.46. 1) Disable concurrent JIT if we cannot write 64-bit values atomically. Most of the chips we run on have no problem doing 64-bit atomic writes, and in that case, we completely recover the perf lost from enabling concurrent JIT (and in fact gain perf). We detect LPAE, and if it is present, skip the store barriers that were previously needed to guarantee we didn't dereference a bad cell. 2) Clear value profiles The 0 value is not the empty JSValue, poluting our profiles. We manually clear them, and our profiling works much better. 3) Tune various options I tuned many thresholds based on what worked on my machine. This probably requires a second round of tuning on a smaller device. 4) Turn off SIMD SIMD::find is a regression on 32-bit due to some fallback paths. Overall, on my Neoverse N1, I get that after this patch, 2.46 is 26% faster than 2.38 when excluding wasm subtests. There are still some regressed subtests worth investigating, with as much as an 11% regression.
justinmichaud
force-pushed
the
eng/2.46-perf-fixes
branch
from
d00c8c1 to
f8ace02
Compare
|
A follow-up on the perf testing: I needed to disable OMG on armv7, plus pick a few bug fixes. I'll land those separately. With that, I get: With concurrent JITSpeedometer 2.1 — 2.46 is 1.47× faster (48.6 → 71.4 runs/min, p ≈ 0) JetStream 2.2 — 2.46 is 1.26× faster overall (48.4 → 61.1, p ≈ 0)
|
|
I'm running the no-cjit test now. I am running Speedometer 2 and JS2 since they also run on 238, but 246 32-bit can run SP3 and most of JS3 for future testing. |
|
With cjit off, we get:
with the following regressions: prepack-wtb 1.579→0.843, Babylon 1.577→0.921, Box2D 1.401→0.850, earley-boyer 1.193→0.793, delta-blue 1.191→0.872 Compile times in general appear to be increased, but we still win overall. Now I will smoke test this patch on rpi3 |
2 participants
#1691
This patch makes some simple fixes to improve 32-bit performance on 2.46.
Most of the chips we run on have no problem doing 64-bit atomic writes, and in that case, we completely recover the perf lost from enabling concurrent JIT (and in fact gain perf).
We detect LPAE, and if it is present, skip the store barriers that were previously needed to guarantee we didn't dereference a bad cell.
The 0 value is not the empty JSValue, poluting our profiles. We manually clear them, and our profiling works much better.
I tuned many thresholds based on what worked on my machine. This probably requires a second round of tuning on a smaller device.
SIMD::find is a regression on 32-bit due to some fallback paths.
Overall, on my Neoverse N1, I get that after this patch, 2.46 is 26% faster than 2.38 when excluding wasm subtests. There are still some regressed subtests worth investigating, with as much as an 11% regression.
f8ace02