Closed Bug 1688828 Opened 3 years ago Closed 3 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: