Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

map: revisit batch per-CPU API #1271

Closed
lmb opened this issue Dec 13, 2023 · 1 comment
Closed

map: revisit batch per-CPU API #1271

lmb opened this issue Dec 13, 2023 · 1 comment
Labels
release-blocker Needs resolution before the next release

Comments

@lmb
Copy link
Collaborator

lmb commented Dec 13, 2023

The proposed API in #1192 for batch per-CPU operations is:

keys := make([]K, n)
values := make([]V, n*possibleCPU)
m.BatchUpdate(keys, values)

So instead of a nested [][]K we have a flat slice. This matches the memory representation the kernel expects 1:1 and opens up the possibility for zero copy optimisations later. (We currently do copies due to alignment issues, and might have to do that in the future as well.) Unfortunately it's also very confusing to write code that deals with this, both as a user and when maintaining the library.

Before the next release we should investigate how much more overhead [][]K would be.

@lmb
Copy link
Collaborator Author

lmb commented Feb 15, 2024

I don't see how we can both make the API efficient and at the same time preserve the nestedness of the type. What we'd like is a slice of arrays like

[][PossibleCPU]T

but of course PossibleCPU changes at runtime and therefore can't be an array. Ultimately the right answer might be to hide this behind MapIterator or similar.

@lmb lmb closed this as completed Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-blocker Needs resolution before the next release
Projects
None yet
Development

No branches or pull requests

1 participant