Comparing the transformation of the encoding to prepare for the introduction of separate concretization of build dependencies:

develop: 7dc485d
PR: 8669f3e

radiuss.8669f3e3f153de172329bc3394991b64f530665c.csv
radiuss.develop.csv
radiuss.txt

So far only a single node is allowed, and the runtime is expected further slow-downs as we introduce separate concretization of build dependencies.¹

Benchmark done with:

• Spack: 0.21.0.dev0 (8669f3e)
• Python: 3.8.10
• Platform: linux-ubuntu20.04-icelake
• Concretizer: clingo

This is a plot of the slow-down due to the more complex encoding in 9742a8e and 4285810 to map nodes to packages.

Both plots have been obtained allowing a single nodes per package, and they reflect the effect of the added complexity in the encoding.

develop: 4285810
PR: d761d92

radiuss.d761d926a82e8ed7a23c54d8ce608760da764f71.csv
radiuss.develop.csv
radiuss.txt

The encoding passed a first sanity check, i.e. it passes the unit tests under the same conditions of the previous encoding. Now we need to recover performance. Three possible step forward:

1. Tune the heuristic for this new encoding
2. Deduplicate conditions and impositions from the directives
3. Reduce the number of "possible dependencies" in a build

Compared to #38447 (comment), this is the effect of the following optimizations:

1. 10129b4 (remove the optimization on literals if we know we have to solve for all of them)
2. 8499bc1 (deduplicate condition triggers and effects)
3. fa060e5 (use cycle detection in ASP only as a fall-back)
4. 8b845bd (reduce the number of unification sets)

As before, I am testing against develop under the same conditions, so I allow just one node per package.

develop: 4285810
PR: 8b845bd

radiuss.8b845bd4b157a0f03eb46313b98ef15977960417.csv
radiuss.txt
radiuss.develop.csv

Notes

• The optimizations done here also apply to develop, at least conceptually.
• visit is still slower, because it falls back to using cycle detection - since the optimal solution without the integrity constraint has cycles¹
• Removing cycle detection is a huge win in solving time (now), and an enabler for grounding with multiple nodes

Latest commit is a step towards getting full separation:

• 6779636 allows each software tagged "build-tools " and used as a build dependency to have its own unification set. This keeps the number of unification sets low, but serves the purpose of separating over e.g. cmake, gamke, py-setuptools etc.
• d340ba6 encodes a couple of rules differently, to enable enforcing different targets and / or compilers for specs in the "root" unification set vs. other unification sets

develop: 78f33bc
PR: d340ba6

radiuss.d340ba67cb3650a78b2f14fcab4f5c6bb89be244.csv
radiuss.develop.csv
radiuss.txt

Adding these rules to a solve (by inserting them in display.lp):

attr("node_target_set", PackageNode, "x86_64_v4") :- unification_set("root", PackageNode), attr("node", PackageNode).
attr("node_target_set", PackageNode, "x86_64_v2") :- unification_set(SetID, PackageNode), attr("node", PackageNode), SetID != "root".
attr("node_compiler_version_set", PackageNode, "oneapi", "2023.1.0") :- unification_set("root", PackageNode), attr("node", PackageNode).
attr("node_compiler_version_set", PackageNode, "gcc", "9.4.0") :- unification_set(SetID, PackageNode), attr("node", PackageNode), SetID != "root".
:- provider(node(_, Package), node(_, "mpi")), Package != "openmpi".

and making the default dependency just link, I was able to get a "full separation" of build dependencies wrt link-run dependencies, and obtained the following DAG for trilinos:

Latest results:

develop: 78f33bc
PR: 69371ae

radiuss.develop.csv
radiuss.69371aee145027cfbf07c8b4a3e0fa6e340c4fa5.csv
radiuss.txt

@tgamblin @becker33 With the exception of visit, which takes twice as much as before due to cycle detection, many other specs are ~20% faster in this branch than on develop - when we allow a single node per package.

I am able to solve #38447 (comment) in a "fully separate way" in ~15 seconds by adding the 5 rules you see in the comment (to help looking for a solution). Grounding doesn't seem to be an issue anymore, as long as we select what we allow to fork with a finer granularity than what we tried before.

I think this PR is ready for a review, to merge concretize.lp in develop and have a common base for further changes in the model. There is still (a lot of?) space for further optimizations, but I would leave them for future PRs.

The latest commit c84df00 solves #38447 (comment) according to what we decided in DM.

Here's the build of openmpi in the e4s-oneapi stack: https://gitlab.spack.io/spack/spack/-/jobs/7985353

Comparing performance:

radiuss-8a2efcf.csv
radiuss-c84df00.csv
radiuss.txt

The change in the concretizer didn't impact performance in the benchmark.

Looks like there's a bug in how concretizer error messages are formatted:

Before

   1. Cannot select a single "version" for package "py-jupyter-packaging"

After

   1. Cannot select a single "version" for package "NodeArgument(id='0', pkg='py-jupyter-packaging')"

Also here:

==> Warning: using "NodeArgument(id='0', pkg='python')@3.7.17" which is a deprecated version