New package: Intel OneAPI by scheibelp · Pull Request #19506 · spack/spack

scheibelp · 2020-10-24T02:21:50Z

This includes the icx/ifx executables. and is intended to

This is similar to #19033 but differs in that this is a separate package rather than exposed as a new version of intel. This package does not appear to have the same requirements so it looked like it could be separated out.

At least one concern brought up by @rscohn2 was that both this and and Spack's intel package provide icc executables, so it may be confusing for users who want to install icc. I think this could be resolved by adding an icc virtual (provided by intel and intel-oneapi).

@rscohn I had a couple questions:

Is icc distinct from icx (i.e. do they produce different compiled executables)?
If the answer to the first question is "no", will icx be completely replacing icc at some point in the future?

TODOs

I may need to tweak this to support bootstrapping of compiler installs (so that spack install foo%intel-oneapi will automatically install intel-oneapi

See also: #19330 (which adds the compiler definition)

rscohn2

icc is distinct from icx. I expect the icx name to be used indefintely.

var/spack/repos/builtin/packages/intel-oneapi/package.py

rscohn2 · 2020-10-24T12:33:50Z

var/spack/repos/builtin/packages/intel-oneapi/package.py

+             '-s', '-a', '-s', '--action', 'install',
+             '--eula', 'accept',
+             '--components',
+             ('intel.oneapi.lin.dpcpp-cpp-compiler-pro'


This package will be hardwired to install the compilers. What do you think about having a base oneapi class, where components is a member that is overridden by derived classes InteloneAPICompilers?

What are all the components that are available? Could it make sense to install them all here?

What do you think about having a base oneapi class, where components is a member that is overridden by derived classes InteloneAPICompilers?

This could be useful. It would be simplest if the component sets did not overlap between packages. Do you see a reason for Spack packages with overlapping component sets (e.g. two packages which include intel.oneapi.lin.dpcpp-cpp-compiler-pro in --components)?

compiler, onemkl, onedal, oneccl, onednn, onetbb. TBB is relatively small (< 100 mbytes) and DAL and MKL are much larger 500+ mbytes. Downloading and installing them all would not be convenient for some people.

There are some dependencies between components. Is there a way to express dependencies between packages in spack?

Sorry I thought MKL etc. were part of the Base Toolkit e.g. described here and the HPC Toolkit (which provided icx etc.) did not provide those.

Regarding the size: the install as of now appears to occupy 4.4 GB, so I don't consider it prohibitively expensive to add DAL/MKL by default.

You are correct, MKL is part of base toolkit. Download size of basekit is 2 GB, hpckit is 1 GB. Installed size of basekit is 10+ GB.

My thought was that IntelOneapi would be a base class with the code that:

knows how to invoke the installer

has the URL's for basekit/hpckit.

Has a dict that maps packages, e.g. mkl to the component name/installer that contains it.
It would never be used directly to install anything.

All the packages that install something:

intel-oneapi-compilers

intel-oneapi-mkl

intel-oneapi-tbb

...
would inherit from IntelOneapi, and override the set of packages that are installed. They would not have code to invoke the installer, or have to know whether it was in basekit/hpckit, etc.

Or maybe we don't need to make the installer code a baseclass, but a python module with utilities that all the oneapi packages rely on.

Then it sounds best to use the standalones. Individual components may have out of cycle releases that would only be available via a standalone (not basekit).

Interesting: where would I download these individual packages?

Also, is this true of the components that come with the HPC toolkit? That is: is there a download for just the icx/ifx compiler?

The standalones will be available in a few weeks. I have not seen them yet and do not know how they have decomposed the compilers.

The standalones are available. https://software.intel.com/content/www/us/en/develop/articles/oneapi-standalone-components.html#dpcpp-cpp

How do you want to proceed? Unless you want to do it, I can take the file here and split it up into the base class for intel packages and then individual packages for each intel component.

Unless you want to do it, I can take the file here and split it up into the base class for intel packages and then individual packages for each intel component.

@rscohn2 sorry for the late response: that would be extremely useful IMO if you were to do it.

Does each component use this same script? For example from the linked site I see there is a download for MKL at https://registrationcenter-download.intel.com/akdlm/irc_nas/17402/l_onemkl_p_2021.1.1.52_offline.sh - I assume an MKL package could refer to this link directly without needing to use ./l_HPCKit_b_%s_offline.sh). Or is the idea that generally speaking this and each component needs a similar set of environment variables and options and differs in terms of --component?

Also I'm assuming that icx and icc are still distributed together (although from your comment above dpcpp is available as a separate component and would not need to be included with the package that installs icx)

Also I'm assuming that icx and icc are still distributed together (although from your comment above dpcpp is available as a separate component and would not need to be included with the package that installs icx)

To clarify, if possible it would be good for future usage to separate out these compilers. It's fine if that won't work out, but if it's easy to do I think that will make compiler selection easier in the future. I got the impression that would not be easy for icx/icc but since dpcpp looked like a separate component I thought it might be possible in that case.

In more detail: fairly soon Spack will start treating compilers like other dependencies (e.g. libraries), so ideally it can retrieve the C compiler for a package with normal querying syntax like root_spec['c'] and use that with the compiler wrapper; in that case the package would have an executable property which refers to the compiler exe; if the package contains multiple C compiler executables then this will be ambiguous. Also note that the way Spack currently models things, it won't be an issue for a single package to provide multiple compiler executables for the same language.

rscohn2 · 2020-10-24T12:38:25Z

var/spack/repos/builtin/packages/intel-oneapi/package.py

+            install(f, dst)
+
+    # TODO: this package includes icc as well as icx. Question: is icc a link
+    # to icx?


icx is our next gen compiler that uses LLVM. icc is our older compiler. We expect users to transition from icc to icx, but it might take several years.

Will this installer be the only way to get the icc compiler "going forwards"?

You can use apt/yum and this installer.

rscohn2 · 2020-10-24T12:39:23Z

var/spack/repos/builtin/packages/intel-oneapi/package.py

+              ':intel.oneapi.lin.ifort-compiler'),
+             '--install-dir', prefix)
+
+        # preserve config and logs


I am checking if there is a command line option that would make this more direct.

Installer team confirmed that setting TMPDIR and HOME is the best way to control where the files are put.

OK - based on that it sounds like this is the best that can be done?

I'll say I originally copied this over from #19033 without giving it much thought, but we typically reserve .spack/ for internal Spack usage. In this case I think it's worthwhile to keep logs. Also note that we generally capture everything printed to stdout/stderr and store that in .spack/spack-build-out.txt, so unless these logs are created by opening/writing files this would already be covered.

Finally, I'm inspecting the .spack directory and not seeing any additional log files there after installing this package (i.e. anything that fits the pattern passed to glob). Is it possible for no such files to exist?

The installer puts a log file in the install dir that summarizes the entire install. I think that is sufficient. In tmpdir it writes detailed log files for the install of each component. I don't think you need it, but if you want it, then this glob would find the files relative to tmpdir: */*/*/*.log. Note that this could change in the future because they assume a human is looking at the logs.

…to work for OS other than Linux)

tldahlgren · 2020-12-09T19:12:57Z

Closing and re-opening this PR to see if it can get past the two required checks.

tldahlgren · 2020-12-14T19:33:39Z

@scheibelp @tgamblin @rscohn2 Is there any way to up the priority on this? There is at least one ECP team waiting on the PR and it would be great to have their package(s) be examples for an event in January.

rscohn2 · 2020-12-14T20:42:25Z

@tldahlgren I can work on it. If I did these first, would it likely cover their needs: icc, dpcpp, ifort, mkl?

tldahlgren · 2020-12-14T21:00:44Z

@tldahlgren I can work on it. If I did these first, would it likely cover their needs: icc, dpcpp, ifort, mkl?

Thanks! Perhaps for some teams, but I've heard there are other things needed, such as igc and pti-gpu.

rscohn2 · 2020-12-15T13:06:24Z

@tldahlgren igc and pti-gpu are distributed differently. Can you ask the teams to file an issue here if they want that? Please mention me and I can look for someone to work on it. I will open an issue for oneapi tools to be a place for requests.

scheibelp · 2021-01-09T00:30:52Z

This can be closed since #20411 was merged.

scheibelp added 4 commits October 23, 2020 18:00

add new package for installation of oneapi

0751f7a

add TODO about compiler exe properties

09eff75

fix imports, install method signature

107c7c2

flake edit

459fa64

rscohn2 reviewed Oct 24, 2020

View reviewed changes

adamjstewart added new-package oneapi labels Oct 25, 2020

include details in docstring; add cc definition (needs to be updated …

258a73f

…to work for OS other than Linux)

tldahlgren added ecp intel labels Dec 9, 2020

tldahlgren closed this Dec 9, 2020

tldahlgren reopened this Dec 9, 2020

tldahlgren added the impact-high label Dec 14, 2020

rscohn2 mentioned this pull request Dec 15, 2020

Add packages for intel oneapi components #20403

Open

scheibelp mentioned this pull request Dec 16, 2020

add intel-oneapi packages #20411

Merged

scheibelp closed this Jan 9, 2021

Conversation

scheibelp commented Oct 24, 2020

Uh oh!

rscohn2 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scheibelp Oct 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scheibelp Oct 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rscohn2 Oct 27, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tldahlgren commented Dec 9, 2020

Uh oh!

tldahlgren commented Dec 14, 2020

Uh oh!

rscohn2 commented Dec 14, 2020

Uh oh!

tldahlgren commented Dec 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rscohn2 commented Dec 15, 2020

Uh oh!

scheibelp commented Jan 9, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

scheibelp Oct 26, 2020 •

edited

Loading

scheibelp Oct 26, 2020 •

edited

Loading

rscohn2 Oct 27, 2020 •

edited

Loading

tldahlgren commented Dec 14, 2020 •

edited

Loading