buffer: more copy optimizations

[ronag]

config	baseline	view-level API	median Δ
partial, 8 B	42.0 M/s	62.8 M/s	+49%
full, 8 B	42.2 M/s	62.4 M/s	+48%
partial, 128 B	42.0 M/s	63.1 M/s	+50%
full, 128 B	42.2 M/s	61.7 M/s	+46%
partial, 1024 B	37.8 M/s	55.1 M/s	+46%
full, 1024 B	35.1 M/s	47.3 M/s	+35%

Add v8::ArrayBufferView::CopyArrayBufferViewBytes, which copies a byte
range from one ArrayBufferView to another. Unlike the existing
v8::ArrayBuffer::CopyArrayBufferBytes, it operates on the views: it
resolves each view's data pointer directly (JSTypedArray::DataPtr /
DataView::data_pointer) and reads the backing buffer's shared/immutable/
detached flags as plain field loads, without ever materializing or
fetching the views' ArrayBuffers.

This exists because materializing the ArrayBuffer is expensive. Profiling
Buffer.prototype.copy (perf, AMD EPYC 9135, x86-64) showed that for small
copies the dominant native cost is ArrayBufferView::Buffer() ->
JSTypedArray::GetBuffer() -- ~25% of total runtime, paid on every call
(not just first materialization) and incurred twice (source and target).
Add ByteOffset() (~7%) and IsSharedArrayBuffer() (~6%) and roughly 38% of
a small copy is spent turning two views into ArrayBuffers and querying
them piecemeal, while the actual memmove is ~4%. Routing the node binding
through CopyArrayBufferBytes forces all of that onto the embedder side; a
view-level entry point folds it into a single call of cheap field reads.

Byte ranges are clamped to both views' byte lengths. Nothing is copied
when the source is detached/out-of-bounds or the target is detached/
out-of-bounds or backed by an immutable ArrayBuffer; the number of bytes
actually copied is returned. When both views are backed by a
SharedArrayBuffer a relaxed-atomic memmove is used, honoring the
SharedArrayBuffer memory model; any other combination performs a plain
memmove on the backing store (matching CopyArrayBufferBytes).

Carried as a floating patch; v8_embedder_string is bumped to -node.22
accordingly. It is the natural sibling of the CopyArrayBufferBytes API
added in the preceding floating patch and touches nothing but the public
ArrayBuffer/ArrayBufferView API.

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/security-wg
• @nodejs/v8-update

[ronag]

@targos @addaleax @joyeecheung This is a relatively trivial v8 patch. Would you be comfortable with floating this? I've already spent money on funding work to upstream CopyArrayBufferBytes to V8 and not sure I can spend much more.

[ronag]

I've tried the CopyArrayBufferBytes implementation with LTO enabled and the compiler is not able to inline things properly.

[ronag]

So this is basically what we tried to upstream to V8 but was rejected and turned into the slower CopyArrayBufferBytes.

[joyeecheung]

Can you explain why the upstream rejected this patch and why the reason wouldn't apply here?

[ronag]

https://chromium-review.googlesource.com/c/v8/v8/+/7735151

They preferred an implementation that matched the spec.

[joyeecheung]

From the thread it doesn't look like the point about not materialising views provides better performance was ever communicated during the code review in the upstream? Have you tried upstreaming something citing performance numbers of the two different versions?

[ronag]

I can't spend more money on this. So either someone will have to help with upstreaming (I don't have anyone that can do V8 stuff), land this as is or close this. I can always land it on a fork.

I think the value of this is quite high.