WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
239936
[JSC] Add fast path to TypedArray.from
https://bugs.webkit.org/show_bug.cgi?id=239936
Summary
[JSC] Add fast path to TypedArray.from
Jarred Sumner
Reported
2022-04-30 21:30:21 PDT
Created
attachment 458644
[details]
microbenchmark TypedArray.from(otherTypedArrayView) uses Symbol.iterator when it could use memmove() or possibly memcpy. A microbenchmark is attached that runs in both JSC shell and node. On macOS 12.3 aarch64 M1X For 1 MB: - JSC: 22ms - Node : 0.13ms For 32 MB: - JSC: 274ms - Node: 4ms If TypedArray.prototype.set[0] is used in TypedArrayConstructor.js when !mapFn && @isTypedArrayView(arrayLike), that becomes: For 1 MB: - JSC: 22ms - JSC (modified): 0.4ms - v8 9.6 (Node 17.7.1): 0.13ms For 32 MB: - JSC: 274ms - JSC (modified): 5ms - v8 9.6 (Node 17.7.1): 4ms It isn't precisely correct to use TypedArray.prototype.set, but it shows roughly what the numbers would look like after this is fixed. It does seem that V8 is consistently slightly faster after this change though, which means there is still something more to do here. Maybe it could allocate uninitialized memory because it will copy directly from the other typed array view? V8's optimization for TypedArray.from:
https://github.com/v8/v8/blob/f32335fea75b7bde495e0800d7f7349253f81a7c/src/builtins/typed-array-from.tq#L167
[0]:
https://gist.github.com/Jarred-Sumner/543b94142de9f17a9ec86e9dac5cf171#file-typedarrayconstructor-js
Attachments
microbenchmark
(462 bytes, text/javascript)
2022-04-30 21:30 PDT
,
Jarred Sumner
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2022-05-07 21:31:12 PDT
<
rdar://problem/92917413
>
Yusuke Suzuki
Comment 2
2022-05-09 03:24:46 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/564
Yusuke Suzuki
Comment 3
2022-05-09 03:45:10 PDT
Right condition to take this fast path is actually subtle :)
Yusuke Suzuki
Comment 4
2022-07-28 15:18:58 PDT
BTW, it seems that SpiderMonkey and V8 optimize this function incorrectly. The following test pass only in JSC (and from the spec, JSC's behavior is correct since we use ArrayIterator, which uses "length" property, not TypedArrayLength). function shouldBe(actual, expected) { if (actual !== expected) throw new Error('bad value: ' + actual); } var array = new Uint8Array(128); Reflect.defineProperty(array, 'length', { value: 42 }); var result = Uint8Array.from(array); shouldBe(result.length, 42);
EWS
Comment 5
2022-07-30 14:15:09 PDT
Committed
252976@main
(1b440efcb4ae): <
https://commits.webkit.org/252976@main
> Reviewed commits have been landed. Closing PR #564 and removing active labels.
André Bargull
Comment 6
2022-08-04 23:43:56 PDT
(In reply to Yusuke Suzuki from
comment #4
)
> BTW, it seems that SpiderMonkey and V8 optimize this function incorrectly. > The following test pass only in JSC (and from the spec, JSC's behavior is > correct since we use ArrayIterator, which uses "length" property, not > TypedArrayLength).
It's actually the other way around. JSC is incorrectly using the "length" [1] property, whereas the spec mandates that for objects with a [[TypedArrayName]] internal slot, the [[ArrayLength]] internal slot is read [2]. :-) [1]
https://github.com/WebKit/WebKit/blob/3f019cf4b5d2b381db5af9d2751583f7871ba8bf/Source/JavaScriptCore/builtins/ArrayIteratorPrototype.js#L53
[2]
https://tc39.es/ecma262/#sec-createarrayiterator
Yusuke Suzuki
Comment 7
2022-08-05 00:49:44 PDT
(In reply to André Bargull from
comment #6
)
> (In reply to Yusuke Suzuki from
comment #4
) > > BTW, it seems that SpiderMonkey and V8 optimize this function incorrectly. > > The following test pass only in JSC (and from the spec, JSC's behavior is > > correct since we use ArrayIterator, which uses "length" property, not > > TypedArrayLength). > > It's actually the other way around. JSC is incorrectly using the "length" > [1] property, whereas the spec mandates that for objects with a > [[TypedArrayName]] internal slot, the [[ArrayLength]] internal slot is read > [2]. :-) > > [1] >
https://github.com/WebKit/WebKit/blob/
> 3f019cf4b5d2b381db5af9d2751583f7871ba8bf/Source/JavaScriptCore/builtins/ > ArrayIteratorPrototype.js#L53 > [2]
https://tc39.es/ecma262/#sec-createarrayiterator
Oh, interesting. We can make the implementation simpler.
Yusuke Suzuki
Comment 8
2022-08-05 01:21:31 PDT
(In reply to Yusuke Suzuki from
comment #7
)
> (In reply to André Bargull from
comment #6
) > > (In reply to Yusuke Suzuki from
comment #4
) > > > BTW, it seems that SpiderMonkey and V8 optimize this function incorrectly. > > > The following test pass only in JSC (and from the spec, JSC's behavior is > > > correct since we use ArrayIterator, which uses "length" property, not > > > TypedArrayLength). > > > > It's actually the other way around. JSC is incorrectly using the "length" > > [1] property, whereas the spec mandates that for objects with a > > [[TypedArrayName]] internal slot, the [[ArrayLength]] internal slot is read > > [2]. :-) > > > > [1] > >
https://github.com/WebKit/WebKit/blob/
> > 3f019cf4b5d2b381db5af9d2751583f7871ba8bf/Source/JavaScriptCore/builtins/ > > ArrayIteratorPrototype.js#L53 > > [2]
https://tc39.es/ecma262/#sec-createarrayiterator
> > Oh, interesting. We can make the implementation simpler.
Will be fixed in
https://github.com/WebKit/WebKit/pull/3038
, it makes implementation simpler!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug