Specific targets by becker33 · Pull Request #3206 · spack/spack

becker33 · 2017-02-21T18:13:02Z

Resolves #2379

Allow spack to detect target at a finer granularity.

Moves toward using the granularity of the -march option for the gnu compiler toolchain.

Modifications to be done to add the feature

Tests to be added to the suite

Ensure that high-end machines with custom build / detection logic (Cray, BG/Q) still work properly
Test that defaults in packages.yaml can set the target at any scope
Test the semantic of llnl.util.cpu.MicroArchitecture, including partial ordering
Ensure that we don't dump unicode to yaml configuration even in Python 2
Test that we are injecting the right compiler flags for relevant pairs of target / compiler
Test that target names don't contain dashes
Test that spack find works properly (was broken by 43d5e97 but not caught by unit tests)
Test micro-architecture detection for common targets

becker33 · 2018-09-13T00:48:56Z

@scheibelp this is the architecture PR we were discussing. It still needs a bunch of work, especially for ARM architectures.

becker33 · 2019-06-20T12:49:25Z

@mamelara yes this branch is in active development.

alalazo · 2019-06-27T10:14:31Z

@tgamblin @becker33 The last commit adds micro-architecture information to the spec YAML file and tries to maintain backward compatibility. For instance zlib concretized for broadwell would look like:

spec:
- zlib:
    version: 1.2.11
    arch:
      platform: linux
      platform_os: ubuntu18.04
      target:
        name: broadwell
        vendor: GenuineIntel
        features:
        - adx
        - aes
        - avx
        - avx2
        - bmi1
        - bmi2
        - f16c
        - fma
        - mmx
        - movbe
        - pclmulqdq
        - popcnt
        - rdrand
        - rdseed
        - sse
        - sse2
        - sse4_1
        - sse4_2
        - ssse3
        generation: 0
        parents:
        - haswell
    compiler:
      name: gcc
      version: 9.0.1
    namespace: builtin
    parameters:
      optimize: true
      pic: true
      shared: true
      cflags: []
      cppflags: []
      cxxflags: []
      fflags: []
      ldflags: []
      ldlibs: []
    hash: os3djb57dqdzhaqsl2n7iefz3gwombyi

while for x86_64 would be instead:

spec:
- zlib:
    version: 1.2.11
    arch:
      platform: linux
      platform_os: ubuntu18.04
      target: x86_64
    compiler:
      name: gcc
      version: 9.0.1
    namespace: builtin
    parameters:
      optimize: true
      pic: true
      shared: true
      cflags: []
      cppflags: []
      cxxflags: []
      fflags: []
      ldflags: []
      ldlibs: []
    hash: tn4qvs7g6r45dipq6kvg4ggs6rts3m7s

alalazo · 2019-06-29T12:09:38Z

The last commit introduces checks on the compiler to ensure it can optimize for the requested architecture:

$ spack spec hdf5 target=icelake %[email protected]
Input spec
--------------------------------
hdf5%[email protected] arch=linux-None-icelake

Concretized
--------------------------------
==> Error: cannot produce optimized binary for micro-architecture "icelake" with [email protected] [supported compiler versions are 8:]

At the moment Spack errors out if the required target is not supported and we have info on the compiler in the JSON file. An alternative behavior would be to just print a warning and don't pass any optimization flag (my personal preference goes on the current behavior).

If we don't have information on the compiler Spack will proceed and avoid using any optimization flag, for instance:

$ spack spec hdf5 target=icelake %clang
Input spec
--------------------------------
hdf5%clang arch=linux-None-icelake

Concretized
--------------------------------
[email protected]%[email protected]~cxx~debug~fortran~hl+mpi+pic+shared~szip~threadsafe arch=linux-ubuntu18.04-icelake
    ^[email protected]%[email protected]~cuda+cxx_exceptions fabrics=none ~java~legacylaunchers~memchecker~pmi schedulers=none ~sqlite3~thread_multiple+vt arch=linux-ubuntu18.04-icelake
        ^[email protected]%[email protected]~cairo~cuda~gl+libxml2~nvml+pci+shared arch=linux-ubuntu18.04-icelake
            ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                    ^[email protected]%[email protected] patches=3877ab548f88597ab2327a2230ee048d2d07ace1062efe81fc92e91b7f39cd00,c0a408fbffb7255fcc75e26bd8edab116fc81d216bfd18b473668b7739a4158e,fc9b61654a3ba1a8d6cd78ce087e7c96366c290bc8d2c299f09828d793b853c8 +sigsegv arch=linux-ubuntu18.04-icelake
                        ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
            ^[email protected]%[email protected]~python arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected]+optimize+pic+shared arch=linux-ubuntu18.04-icelake
            ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                    ^[email protected]%[email protected]+cpanm patches=0eac10ed90aeb0459ad8851f88081d439a4e41978e586ec743069e8b059370ac +shared+threads arch=linux-ubuntu18.04-icelake
                        ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                            ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake
                                ^[email protected]%[email protected]~symlinks~termlib arch=linux-ubuntu18.04-icelake
                ^[email protected]%[email protected] arch=linux-ubuntu18.04-icelake

will concretize but won't use any march flag because we don't have (yet) any information concerning clang in the JSON file.

tgamblin · 2019-07-01T00:20:37Z

@alalazo:

At the moment Spack errors out if the required target is not supported and we have info on the compiler in the JSON file. An alternative behavior would be to just print a warning and don't pass any optimization flag (my personal preference goes on the current behavior).

I agree with the current behavior -- if we say the binary is for icelake, it should really mean we tried to optimize for icelake. I think the error message above should print out something about what targets are supported by the selected compilers -- e.g., it might say something like "most recent supported architecture is skylake_avx512", or list the possible options (indicating which is the most recent).

This probably also means that when the target isn't specified, Spack should scale it back to somethign that's good for the selected compiler. e.g., if you say spack install foo %[email protected] and you're on a cascadelake machine, I think the concretizer should set target to skylake_avx512. What do you think?

tgamblin

@becker33 @alalazo: I did an initial pass over this. It looks like it's coming along well but I have some requests and I figure I better get started early.

@alalazo: can you address these or should we get @becker33 to?

lib/spack/env/cc

lib/spack/llnl/util/cpu.py

lib/spack/spack/test/cmd/find.py

lib/spack/spack/test/cmd/release_jobs.py

lib/spack/spack/test/data/modules/tcl/alter_environment.yaml

lib/spack/spack/test/data/targets/linux-centos7-power8

tgamblin · 2019-07-21T23:32:58Z

@alalazo @becker33: high level comment: we should allow the default target to be overridden somehow, I guess in packages.yaml, so that people can prefer to build everything with some generic architecture (i.e., x86_64) if they so choose. I know @gartung and the Fermilab folks need this for heterogeneous clusters. @gartung should probably take a look at where this PR is going.

gartung · 2019-07-22T13:32:59Z

I can only comment that we have to compile to the lower common instruction set between AMD and Intel server chips. I believe this is K2(?)

becker33 · 2019-07-22T14:09:25Z

@tgamblin This PR already does allow the default target to be overriden in packages.yaml.

@gartung I think the target is x86-64, unless you happen to know that a particular AMD chip has no instructions that aren't also available on Intel chips.

lib/spack/llnl/util/cpu.py

Since spack#3206, 'spec.architecture.target' returned the microarchitecture target rather than the architecture family. This causes QT 4 to fail to build because it's expecting something like 'x86_64' rather than 'broadwell'. See spack#12914 Erorr message: ``` ==> [2019-09-26-09:37:33.834286] './configure' '-prefix' '/rnsdhpc/code/spack/opt/spack/clang/qt/aguusfi' '-v' '-opensource' '-no-opengl' '-release' '-confirm-license' '-optimized-qmake' '-no-pch' '-no-freetype' '-no-openssl' '-no-sql-db2' '-no-sql-ibase' '-no-sql-oci' '-no-sql-tds' '-no-sql-mysql' '-no-sql-odbc' '-no-sql-psql' '-no-sql-sqlite' '-no-sql-sqlite2' '-shared' '-no-openvg' '-no-nis' '-nomake' 'examples' '-nomake' 'tools' '-no-dbus' '-no-framework' '-fast' '-no-declarative-debug' '-no-gtkstyle' '-no-webkit' '-no-phonon' '-arch' 'broadwell' '-nomake' 'demos' '-cocoa' '-platform' 'unsupported/macx-clang-libc++' '-sdk' '/var/folders/gy/mrg1ffts2h945qj9k29s1l1dvvmbqb/T/s3j/spack-stage/xcode-select/clang/10.0.1-apple/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' Determining system architecture... (Darwin:18.7.0:x86_64) 'macosx' is supported System architecture: 'macosx' Unknown architecture: "broadwell". Supported architectures: x86[i386] ppc x86_64 ppc64 arm armv6 armv7 ```

fixes spack#13073 Since spack#3206 was merged bootstrapping environment-modules was using the architecture of the current host or the best match supported by the default compiler. The former case is an issue since shell integration was looking for a spec targeted at the host microarchitecture. This commit fixes the problem by: 1. Bootstrapping an en modules targeted at generic architectures 2. Looking for generic targets in shell integration scripts

fixes spack#13005 This commit fixes an issue with the name of the root directory for module file hierarchies. Since spack#3206 the root folder was named after the microarchitecture used for the spec, which is too specific and not backward compatible for lmod hierarchies. Here we compute the root folder name using the target family instead of the target name itself and we add target information in the 'whatis' portion of the module file.

#13121) fixes #13005 This commit fixes an issue with the name of the root directory for module file hierarchies. Since #3206 the root folder was named after the microarchitecture used for the spec, which is too specific and not backward compatible for lmod hierarchies. Here we compute the root folder name using the target family instead of the target name itself and we add target information in the 'whatis' portion of the module file.

…13105) fixes #13073 Since #3206 was merged bootstrapping environment-modules was using the architecture of the current host or the best match supported by the default compiler. The former case is an issue since shell integration was looking for a spec targeted at the host microarchitecture. 1. Bootstrap an env modules targeted at generic architectures 2. Look for generic targets in shell integration scripts 3. Add a new entry in Travis to test shell integration

spack#13121) fixes spack#13005 This commit fixes an issue with the name of the root directory for module file hierarchies. Since spack#3206 the root folder was named after the microarchitecture used for the spec, which is too specific and not backward compatible for lmod hierarchies. Here we compute the root folder name using the target family instead of the target name itself and we add target information in the 'whatis' portion of the module file.

…pack#13105) fixes spack#13073 Since spack#3206 was merged bootstrapping environment-modules was using the architecture of the current host or the best match supported by the default compiler. The former case is an issue since shell integration was looking for a spec targeted at the host microarchitecture. 1. Bootstrap an env modules targeted at generic architectures 2. Look for generic targets in shell integration scripts 3. Add a new entry in Travis to test shell integration

becker33 added the WIP label Feb 21, 2017

tgamblin mentioned this pull request Mar 29, 2017

support OpenFOAM package(s) #3528

Merged

tgamblin mentioned this pull request Apr 20, 2017

different installations for the same os/architecture, depending on instruction set of the CPU #3919

Closed

becker33 mentioned this pull request Sep 8, 2017

elpa: add 2017.05.002 and 2017.05.003 #5306

Merged

This comment has been minimized.

Sign in to view

becker33 force-pushed the specific-targets branch from 63bcc18 to be15bb7 Compare June 18, 2019 00:41

becker33 mentioned this pull request Jun 26, 2019

Add platform spack_cross for cross compile environment. #11772

Closed

alalazo mentioned this pull request Jun 27, 2019

Fixed a Python 2.6 parsing error #11867

Merged

tgamblin self-requested a review June 27, 2019 18:03

alalazo force-pushed the specific-targets branch from 7e126b9 to 850545e Compare July 2, 2019 18:43

tgamblin mentioned this pull request Jul 16, 2019

feature: sharing a spack instance #11871

Open

tgamblin added the impact-high label Jul 18, 2019

tgamblin mentioned this pull request Jul 20, 2019

libsharp: Don't add -march=native on ARM #12064

Merged

tgamblin requested changes Jul 21, 2019

View reviewed changes

alalazo force-pushed the specific-targets branch from 3c89366 to fed4916 Compare July 23, 2019 11:25

tgamblin reviewed Jul 26, 2019

View reviewed changes

lib/spack/llnl/util/cpu.py Outdated Show resolved Hide resolved

alalazo mentioned this pull request Aug 6, 2019

Adding singularity command group with recipe|build #11367

Closed

alalazo force-pushed the specific-targets branch 2 times, most recently from 60b064f to 28b2d96 Compare August 11, 2019 13:30

alalazo added the feature A feature is missing in Spack label Aug 12, 2019

adamjstewart mentioned this pull request Aug 14, 2019

What is the status of tensorflow on spack? #9352

Closed

alalazo force-pushed the specific-targets branch from 981a25e to 4ae1faf Compare August 15, 2019 13:16

This was referenced Sep 25, 2019

Fixed query to target for a few packages #12947

Merged

Removed references to '(-march|-mtune|-mcpu)=native' in packages #12948

Merged

spack load error: unable to find modulefile #12915

Closed

sethrj mentioned this pull request Sep 26, 2019

Fix 'arch' string in QT4 due to microarchitecture change #12957

Merged

hartzell mentioned this pull request Oct 1, 2019

Problems with Lmod modulefile names post-PR#3206 #13005

Closed

This was referenced Oct 9, 2019

Add microarchitecture specific flags for Intel compilers #13103

Closed

Add microarchitecture specific flags for LLVM compilers #13104

Closed

alalazo mentioned this pull request Oct 9, 2019

Bootstrap environment modules optimizing for generic architectures #13105

Merged

This was referenced Oct 10, 2019

lmod: module files are written in a root folder named by target family #13121

Merged

Autotools build system to patch config.guess based on a range check #13186

Merged

tgamblin deleted the specific-targets branch October 13, 2019 00:16

alalazo mentioned this pull request Oct 17, 2019

Microarchitecture specific optimizations for LLVM #13250

Merged

tgamblin mentioned this pull request Oct 28, 2019

spack arch return nephalem #13440

Closed

alalazo mentioned this pull request Oct 31, 2019

cannot specify multiple cflags on the command line #12951

Closed

becker33 mentioned this pull request Nov 5, 2019

elpa: prefer 2016.05.004 until sse/avx/avx2 configure phase issues ar… #13530

Merged

This was referenced Nov 18, 2019

llvm patch for installing numba #8123

Closed

netlib-lapack: changed handling of XL and clang compilers for the PPC64LE. #8311

Closed

This was referenced Dec 9, 2019

Cray: Unable to target mic-knl on LANL's Trinity machine #3477

Closed

Spack arch does not recognize KNL cores. #6308

Closed

Lua Modules install path does not contain the correct arch #14098

Closed

Speed of Spack-built executables sub-optimal #6712

Closed

haampie added the hash-change things that will change a lot of hashes label Nov 7, 2024

Conversation

becker33 commented Feb 21, 2017 • edited by tgamblin Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Modifications to be done to add the feature

Tests to be added to the suite

Uh oh!

This comment has been minimized.

becker33 commented Sep 13, 2018

Uh oh!

becker33 commented Jun 20, 2019

Uh oh!

alalazo commented Jun 27, 2019

Uh oh!

alalazo commented Jun 29, 2019

Uh oh!

tgamblin commented Jul 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgamblin commented Jul 21, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gartung commented Jul 22, 2019

Uh oh!

becker33 commented Jul 22, 2019

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

becker33 commented Feb 21, 2017 •

edited by tgamblin

Loading

tgamblin commented Jul 1, 2019 •

edited

Loading

tgamblin commented Jul 21, 2019 •

edited

Loading