Closed Bug 1688828 Opened 5 years ago Closed 5 years ago

Optimize TypedArray length with double result

Categories

(Core :: JavaScript Engine: JIT, task, P3)

task

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
firefox87 --- fixed

People

(Reporter: jandem, Assigned: jandem)

References

Details

Attachments

(10 files)

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.

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: nobody → jdemooij
Status: NEW → ASSIGNED

This seems clearer now that we use IntPtr in more places.

This matches MArrayBufferViewLength.

Depends on D104996

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

Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/087a29c7f317 part 1 - Rename loadArrayBufferViewLengthPtr to loadArrayBufferViewLengthIntPtr. r=anba https://hg.mozilla.org/integration/autoland/rev/6b9201d64b9d part 2 - Optimize typed array length with double result in CacheIR. r=anba https://hg.mozilla.org/integration/autoland/rev/16a6532aae9d part 3 - Transpile LoadTypedArrayLengthDoubleResult in Warp. r=anba https://hg.mozilla.org/integration/autoland/rev/a454b82b3448 part 4 - Optimize TypedArrayByteOffset with double result in CacheIR. r=anba https://hg.mozilla.org/integration/autoland/rev/1797f3729257 part 5 - Change MArrayBufferViewByteOffset to return IntPtr instead of Int32. r=anba https://hg.mozilla.org/integration/autoland/rev/d30c7aaa28bd part 6 - Transpile TypedArrayByteOffsetDoubleResult in Warp. r=anba https://hg.mozilla.org/integration/autoland/rev/cb2c05fdafa9 part 7 - Optimize ArrayBufferByteLength with double result in CacheIR. r=anba https://hg.mozilla.org/integration/autoland/rev/664569686223 part 8 - Rename MArrayBufferByteLengthInt32, change to return IntPtr instead of Int32. r=anba https://hg.mozilla.org/integration/autoland/rev/1d9276690933 part 9 - Transpile LoadArrayBufferByteLengthDoubleResult in Warp. r=anba https://hg.mozilla.org/integration/autoland/rev/7cc18ce3b9a2 part 10 - Replace loadArrayBuffer*Int32 with guardNonNegativeIntPtrToInt32. r=anba
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: