Skip to content

perf(builtin): inline fast paths for slice element stores - #533

Open
rcoreilly wants to merge 1 commit into
s4wave:masterfrom
cogentcore:perf/slice-store-fast-paths
Open

rcoreilly wants to merge 1 commit into
s4wave:masterfrom
cogentcore:perf/slice-store-fast-paths

Conversation

@rcoreilly

Copy link
Copy Markdown
Contributor

This is the second commit of #531, which was not included when #531 merged.

An assignment to a slice element, including a compound one such as s[i] += v, writes through sliceElems and sliceSlot. Like the helpers #531 split, they tried a long chain of representations on every call, so engines did not inline them.

This gives them the same small fast path for a window object, a typed slice or a plain array, with the existing code moved unchanged into slow functions. In the tensor benchmark from #531, a read-modify-write of a tensor element (Cogent Lab, s.Values[s.Index3To1D(i, j, k)] += v) takes 29 ns instead of 34 ns under Node 26.

The full Go test suite, typecheck and the builtin vitest suite pass.

An assignment to a slice element, including a compound one such as
s[i] += v, writes through sliceElems and sliceSlot, which, like the
helpers of the previous commit, tried a long chain of representations.

Give them the same small fast path for a window object, a typed slice or
a plain array, with the existing code in slow functions. A read-modify-
write of a tensor element (Cogent Lab, s.Values[s.Index3To1D(i, j, k)]
+= v) takes 29 ns instead of 34 ns under Node 26.

Signed-off-by: Randall C. O'Reilly <oreilly@ucdavis.edu>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant