Skip to content

fix[next]: fingerprint connectivity tables independently of their array library - #2951

Closed
havogt wants to merge 2 commits into
GridTools:mainfrom
havogt:f124-array-agnostic-key
Closed

havogt wants to merge 2 commits into
GridTools:mainfrom
havogt:f124-array-agnostic-key

Conversation

@havogt

@havogt havogt commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Description

The persistent translation-cache key fingerprints the connectivity tables in the offset provider. A process-pool compile worker (GT4PY_BUILD_JOBS_MODE=process) only receives a host copy of each table, a NumPyArrayConnectivityField. Serial and thread compilation fingerprint the original table instead, which on GPU backends is a CuPyArrayConnectivityField. The two fingerprint differently, so on dace_gpu/gtfn_gpu a cache filled in one mode misses in the other.

A gather connectivity is now fingerprinted by its domain, codomain, skip value and a content fingerprint of its host table, independent of its class and array library. The content fingerprint is memoized per field, so a device table is copied to the host once per process, not on every fingerprint as before.

…ay library

Persistent translation-cache keys fingerprint the connectivity tables in the
offset provider. A process-pool compile worker only receives a host (numpy)
copy of each table, while serial and thread compilation key the original, so
on GPU backends the two keys differed and the cache written in one mode
missed in the other.

Gather connectivities now get their own deconstructor: domain, codomain,
skip value and a content fingerprint of the host table, without the
connectivity class or array library. The table fingerprint is memoized per
connectivity, so a device table is copied to the host once per process.
@havogt

havogt commented Oct 23, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Written by an agent on behalf of @havogt

@havogt
havogt requested a review from egparedes October 23, 2026 15:48
…ory order

A host copy of a connectivity table can come back in a different memory
order than the original (C vs. F), which split the persistent cache key
again for F-ordered tables. Translation does not depend on table strides,
so the table content is fingerprinted in C order.
@havogt

havogt commented Oct 27, 2026

Copy link
Copy Markdown
Contributor Author

This is probably not the solution. Instead conceptually the more promising direction is to avoid passing connectivities verbatim into the optimization pipeline, but a "canonical" connectivity (probably host side). This would also fix the problem in #2924.

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