Optimize TypedArray length with double result
Categories
(Core :: JavaScript Engine: JIT, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox87 | --- | fixed |
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(10 files)
|
Bug 1688828 part 1 - Rename loadArrayBufferViewLengthPtr to loadArrayBufferViewLengthIntPtr. r?anba!
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Fast path support for length > INT32_MAX shouldn't be too hard to implement on top of bug 1687441.
We should probably do the same for the byteOffset and ArrayBuffer byteLength intrinsics, although those are likely less hot.
| Assignee | ||
Comment 1•5 years ago
|
||
I have some patches for this. For a simple micro-benchmark (see below) summing a 5 GB Int8Array I get:
before: 82 seconds
after: 11 seconds
We're not hoisting the bounds check inside the loop and ideally the JIT backend would replace the floating point instructions with IntPtr/Int64 ones, but for now this naive approach should be good enough.
function f(ta) {
var res = 0;
for (var i = 0; i < ta.length; i++) {
res += ta[i];
}
return res;
}
var ta = new Int8Array(5 * 1024 * 1024 * 1024);
for (var i = 0; i < ta.length; i += 2048) {
ta[i] = 1; // Ensure pages are allocated.
}
var t = new Date;
var sum = f(ta);
print(new Date - t);
print(sum);
| Assignee | ||
Comment 2•5 years ago
|
||
This seems clearer now that we use IntPtr in more places.
| Assignee | ||
Comment 3•5 years ago
|
||
Depends on D104993
| Assignee | ||
Comment 4•5 years ago
|
||
Depends on D104994
| Assignee | ||
Comment 5•5 years ago
|
||
Depends on D104995
| Assignee | ||
Comment 6•5 years ago
|
||
This matches MArrayBufferViewLength.
Depends on D104996
| Assignee | ||
Comment 7•5 years ago
|
||
Depends on D104997
| Assignee | ||
Comment 8•5 years ago
|
||
Depends on D104998
| Assignee | ||
Comment 9•5 years ago
|
||
Depends on D104999
| Assignee | ||
Comment 10•5 years ago
|
||
Depends on D105001
| Assignee | ||
Comment 11•5 years ago
|
||
This is simpler and shorter, and it's now easier to see that CacheIR and Warp do
the same thing because they call the same MacroAssembler methods.
On 64-bit platforms, IC code now checks for large lengths also when large ArrayBuffers
are disabled. Warp is already doing that for MNonNegativeIntPtrToInt32.
Depends on D105003
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/087a29c7f317
https://hg.mozilla.org/mozilla-central/rev/6b9201d64b9d
https://hg.mozilla.org/mozilla-central/rev/16a6532aae9d
https://hg.mozilla.org/mozilla-central/rev/a454b82b3448
https://hg.mozilla.org/mozilla-central/rev/1797f3729257
https://hg.mozilla.org/mozilla-central/rev/d30c7aaa28bd
https://hg.mozilla.org/mozilla-central/rev/cb2c05fdafa9
https://hg.mozilla.org/mozilla-central/rev/664569686223
https://hg.mozilla.org/mozilla-central/rev/1d9276690933
https://hg.mozilla.org/mozilla-central/rev/7cc18ce3b9a2
Description
•