Skip to content

feat[next-dace]: bump to dace v2.0-beta1 - #2937

Open
edopao wants to merge 48 commits into
mainfrom
dace_noview_nested_sdfg
Open

edopao wants to merge 48 commits into
mainfrom
dace_noview_nested_sdfg

Conversation

@edopao

@edopao edopao commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

Update dace to v2.0-beta1, which introduces the concept of no-view nested SDFG: the data descriptor for global arrays inside a nested SDFG have to be the same as the outer data descriptors.

ICON-blueline performance comparison w.r.t. main branch:
bench_blueline_stencil_compute

@edopao
edopao added this pull request to stack #2935 October 5, 2026 07:23
@edopao
edopao force-pushed the dace_noview_nested_sdfg branch from d4c4686 to 3b0658d Compare October 5, 2026 13:01
Base automatically changed from bump_dace_version to main October 5, 2026 13:21
@edopao
edopao force-pushed the dace_noview_nested_sdfg branch from 3b0658d to 788525e Compare October 5, 2026 13:21
@edopao
edopao removed this pull request from stack #2935 October 5, 2026 13:22
@edopao

edopao commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

1 similar comment
@edopao

edopao commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao
edopao force-pushed the dace_noview_nested_sdfg branch from 1b31304 to d72f949 Compare October 9, 2026 14:54
@edopao

edopao commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

1 similar comment
@edopao

edopao commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao

edopao commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

The failure in the RoCM CI (test_scan.py::test_solve_triag[dace.run_dace_gpu]) shows a problem in the lowering/optimization: some arrays are dynamically allocated inside the GPU kernel. This is supported in CUDA, not in HIP. However, it should never happen: it is a performance issue.

@edopao

edopao commented Oct 12, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

2 similar comments
@edopao

edopao commented Oct 12, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao

edopao commented Oct 12, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao

edopao commented Oct 12, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run dace-determinism

@edopao

edopao commented Oct 13, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao

edopao commented Oct 13, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run dace-determinism

@edopao

edopao commented Oct 13, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@philip-paul-mueller philip-paul-mueller left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It generally looks okay, but there are some things that must be changed.

@edopao

edopao commented Oct 27, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao edopao left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the review comments. I have included a change in cartesian, as requested by Roman.


# Symbols that the nested SDFG assigns itself, e.g. on an interstate edge or as a
# loop variable. They are not necessarily listed in `nsdfg.symbols`.
reassigned_symbols: set[str] = set()

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, what about inner_written_symbols?

# ones in the parent SDFG (see `NestedSDFG.validate()`), so the symbols they
# use, e.g. in the shape, must have the same name and meaning inside. If the
# nested SDFG uses the name of the symbol for something else, either a data
# container or a symbol, including one it assigns itself, it is renamed there.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to push back the code agent several times to make it realize that renaming of the inner symbols is not unavoidable, and that the old way is also a viable solution. Finally, it got it, but still it prefers to rename the inner symbols, just in one pass:

Fair point — you're right that this is not forced by DaCe. NestedSDFG.validate() only requires the inner descriptor to be equivalent to the parent's after applying the symbol mapping, so keeping the old scheme (fresh symbol inside, mapped to the outer one, descriptor written in the fresh name) also passes validation. I verified this against 2.0.0b1 with a connector whose descriptor uses an inner-written symbol.

The switch to the 1:1 policy is a design tradeoff, and the comment now says exactly that: with 1:1 names, descriptors, offsets and subsets cross the scope boundary verbatim at every nesting level, and no rename-translation machinery is needed anywhere; with fresh incoming names we never scan the graph, but every object crossing the boundary must be rewritten through a per-level rename map — the machinery that was here before, which multiplies with nesting depth and was easy to apply inconsistently.

Your concern about rename robustness across an arbitrary SDFG is what made me hesitate too, but for the pinned DaCe the risk is now bounded and tested: renames are gathered into a single replace_dict call (fixes the repeated full scans), and I verified + regression-tested that replace_dict renames map parameters together with all uses (memlet subsets, tasklet code, ranges) — writing the test also exposed a real gap: map parameters were not detected as inner-bound names at all, which is now fixed.

@edopao
edopao force-pushed the dace_noview_nested_sdfg branch from ae9a3cb to b11af05 Compare October 28, 2026 16:13
@edopao

edopao commented Oct 28, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao
edopao force-pushed the dace_noview_nested_sdfg branch from b11af05 to ae9a3cb Compare October 28, 2026 16:20
@edopao

edopao commented Oct 28, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@edopao

edopao commented Oct 28, 2026

Copy link
Copy Markdown
Contributor Author

cscs-ci run default

@philip-paul-mueller philip-paul-mueller left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks better but I still have some comments.
Also the concat where remapper is still strange, although I am still willing to accept it.

# ones in the parent SDFG (see `NestedSDFG.validate()`), so the symbols they
# use, e.g. in the shape, must have the same name and meaning inside. If the
# nested SDFG uses the name of the symbol for something else, either a data
# container or a symbol, including one it assigns itself, it is renamed there.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can tell your agent that his renaming will also introduce this "dicontinualities" as the renaming will stop at nested SDFGs, thus a symbol_mapping that was before {"name_that_will_be_renamed": "name_that_will_be_renamed"} will become {"name_that_will_be_renamed": "renamed_name"}.

@edopao
edopao force-pushed the dace_noview_nested_sdfg branch from 64eb3a1 to 88d5310 Compare October 29, 2026 10:50

@philip-paul-mueller philip-paul-mueller left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more comments.

@philip-paul-mueller philip-paul-mueller left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

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.

2 participants