Skip to content

solver: penalize language virtuals for each use#51314

Merged
tgamblin merged 1 commit intospack:developfrom
alalazo:bugfix/solver-virtual-preferences
Oct 27, 2025
Merged

solver: penalize language virtuals for each use#51314
tgamblin merged 1 commit intospack:developfrom
alalazo:bugfix/solver-virtual-preferences

Conversation

@alalazo
Copy link
Copy Markdown
Member

@alalazo alalazo commented Sep 17, 2025

This commit changes how penalties for language virtuals are computed so that a penalty is taken each time a non-preferred compiler is used.

Using this environment as an example:

spack:
  specs:
  - "fftw~mpi %c,fortran=llvm"
  packages:
    c:
      prefer: [gcc]
    cxx:
      prefer: [gcc]
    fortran:
      prefer: [gcc]

Before the PR
Every node uses clang as a compiler, since the penalty is taken per provider, and we force clang on fftw.

After the PR
Only fftw uses clang, since a penalty is taken per provider use, so switching other nodes to clang is suboptimal (since gcc is preferred).

@alalazo alalazo added bugfix Something wasn't working, here's a fix concretization labels Sep 17, 2025
@alalazo
Copy link
Copy Markdown
Member Author

alalazo commented Sep 18, 2025

I tried to benchmark this one using this configuration:

packages.yaml
packages:
  gcc:
    externals:
    - spec: [email protected] languages:='c,c++,fortran'
      prefix: /home/culpo/opt/compiler-as-deps/build-tools/.spack-env/view
      extra_attributes:
        compilers:
          c: /home/culpo/opt/compiler-as-deps/build-tools/.spack-env/view/bin/gcc
          cxx: /home/culpo/opt/compiler-as-deps/build-tools/.spack-env/view/bin/g++
          fortran: /home/culpo/opt/compiler-as-deps/build-tools/.spack-env/view/bin/gfortran
    - spec: [email protected] languages:='c,c++,fortran'
      prefix: /usr
      extra_attributes:
        compilers:
          c: /usr/bin/gcc-8
          cxx: /usr/bin/g++-8
          fortran: /usr/bin/gfortran-8
    - spec: [email protected] languages:='c,c++,fortran'
      prefix: /usr
      extra_attributes:
        compilers:
          c: /usr/bin/gcc
          cxx: /usr/bin/g++
          fortran: /usr/bin/gfortran
    - spec: [email protected] languages:='c,c++,fortran'
      prefix: /usr
      extra_attributes:
        compilers:
          c: /usr/bin/gcc-10
          cxx: /usr/bin/g++-10
          fortran: /usr/bin/gfortran-10
  llvm:
    externals:
    - spec: [email protected]+clang~flang+lld~lldb
      prefix: /usr
      extra_attributes:
        compilers:
          c: /usr/bin/clang-12
          cxx: /usr/bin/clang++-12
    - spec: [email protected]+clang~flang~lld+lldb
      prefix: /usr
      extra_attributes:
        compilers:
          c: /usr/bin/clang
          cxx: /usr/bin/clang++
    - spec: [email protected]+clang~flang~lld~lldb
      prefix: /usr
      extra_attributes:
        compilers:
          c: /usr/bin/clang-11
          cxx: /usr/bin/clang++-11
  c:
    prefer:
    - llvm
  cxx:
    prefer:
    - llvm
  fortran:
    prefer:
    - gcc

on this system:

There is one spec, py-cinemascii, that is extremely unstable, also on develop, with that packages.yaml:

radiuss.develop.csv
radiuss.pr.csv

comparison

@haampie
Copy link
Copy Markdown
Member

haampie commented Sep 18, 2025

with 25%/75% |-----|. Median is 10-11% increase in total time.

comparison

@becker33
Copy link
Copy Markdown
Member

I don't think this is what we want. For a solve with a non-default compiler specified on the root, this will make it even more difficult to get the rest of the stack built with the compiler specified on the root.

I think what we need instead is a per-parent penalty on provider duplicates (instead of the current per-duplicate penalty). That will ensure that even when compiler mixing is forced, it won't propagate further up the DAG.

@alalazo
Copy link
Copy Markdown
Member Author

alalazo commented Sep 19, 2025

Can you give an example? The issue that was pointed out is exactly clang on the root, but prefer: [gcc], should use gcc for other nodes. See #51313

@alalazo
Copy link
Copy Markdown
Member Author

alalazo commented Sep 25, 2025

Ping. Can we proceed reviewing this?

@tgamblin tgamblin added this to the v1.1.0 milestone Oct 6, 2025
This commit changes how penalties for language virtuals are computed
so that a penalty is taken each time a non-preferred compiler is used.

Signed-off-by: Massimiliano Culpo <[email protected]>
@tgamblin
Copy link
Copy Markdown
Member

I believe @becker33's concerns are addressed by #51383, which depends on this.

@tgamblin tgamblin merged commit 4743171 into spack:develop Oct 27, 2025
33 checks passed
@alalazo alalazo deleted the bugfix/solver-virtual-preferences branch October 27, 2025 06:37
kshea21 pushed a commit to kshea21/spack that referenced this pull request Nov 4, 2025
This commit changes how penalties for language virtuals are computed
so that a penalty is taken each time a non-preferred compiler is used.

Using this environment as an example:
```yaml
spack:
  specs:
  - "fftw~mpi %c,fortran=llvm"
  packages:
    c:
      prefer: [gcc]
    cxx:
      prefer: [gcc]
    fortran:
      prefer: [gcc]
```
**Before the PR**
Every node uses `clang` as a compiler, since the penalty is taken per
provider, and we force `clang` on `fftw`.

**After the PR**
Only `fftw` uses `clang`, since a penalty is taken per provider use, 
so switching other nodes to `clang` is suboptimal (since `gcc` is preferred).

Signed-off-by: Massimiliano Culpo <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Something wasn't working, here's a fix concretization

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants