Tools
Explore new features and tools within Intel® products, communities, and platforms
90 Discussions

Intel® oneAPI Compilers Packaging and Versioning 2021 2022 2023

Ron_Green
Moderator
1 2 3,598

What’s in a Name?  Intel® oneAPI (oneAPI) Compilers Packaging and Versioning in 2021, 2022, and 2023

 

The Intel® Compilers are a key part of Intel’s oneAPI products.  Our oneAPI compilers provide amazing support for Intel® Architecture CPUs. The kind of support and performance you expect from Intel.  Our new LLVM-based compilers add support for Intel GPUs on top of the performance and features you expect from us for CPUs. But product versioning used for Intel® oneAPI can be confusing and frustrating.  Often you want a simple mapping from oneAPI releases to the compilers in those releases. If you want to immediately go to a table listing oneAPI releases and the compilers that are contained in each, visit our Intel® oneAPI Toolkit Version to Compiler Version Mapping page.  This is a page to bookmark.

In this article we will go over the details in our oneAPI and Compiler versioning.  As part of a deep dive on our versioning, we will  cover these topics:

  1. oneAPI Package Contents
  2. oneAPI Package Versioning for 2021, 2022, and 2023
  3. oneAPI Download Package Naming
  4. Compiler Versions for Compiler Classic and LLVM-based Compilers
  5. Stand-alone Compiler “Component” Download versions

 

oneAPI Package Contents 

 

Our compilers are packaged both in Toolkits and as separate component downloads.  The idea behind Toolkits is to bundle together compilers, libraries, and tools that are commonly used together. For Toolkits, our compilers can be found in these packages: 

  • The Intel® oneAPI Base Toolkit contains the Intel® DPC++/C++ Compiler and an assortment of libraries including MKL and Data Analytics, and in addition contains analyzer tools such as Vtune and Advisor .  In the oneAPI Toolkit, the Intel® DPC++/C++ compiler provides our llvm-based C/C++ compiler enhanced for interpreting SYCL extensions.  Drivers provided for this compiler are ICX, ICPX, and DPCPP.  Intel Fortran is not provided in the Base Toolkit.  Classic Compilers are not provided in Base Toolkits.

  • The Intel® oneAPI HPC Toolkit contains our new llvm-based C/C++ and Fortran compilers.  It also contains the “Classic” compilers ICC/ICPC and IFORT. Drivers provided are:
    • LLVM-based compilers: DPCPP, ICX, ICPX, IFX
    • Classic Compilers:   ICC, ICPC, IFORT

 

The HPC Toolkit also includes the Intel® MPI Library and Intel® Trace Analyzer and Collector along with the Intel® Inspector correctness tool.  Surprisingly, the Intel® oneAPI Math Kernel Library (MKL) is only available in the Base Toolkit and not in the HPC Toolkit as one might expect.  At least not in the version 2021 and 2022 releases.  However, MKL can be downloaded as a separate “component download” that I will describe later in this article.   To get started with a Toolkit, see the Intel® oneAPI Toolkits page.

Toolkits provide a well rounded set of tools.  However, many users just want a compiler package.  Or maybe a compiler and MKL or MPI.  This capability is provided by our  “Single Component Downloads and Runtime Versions”, which I describe in this article. So, if you want to pick and choose your compiler, libraries, and tools use this method rather than a full Toolkit download. 

Runtime Libraries: The Single Component and Runtime Versions page also has links to our compiler runtime library packages. In the past with Intel® Parallel Studio XE we used to name and refer to runtime libraries as “Redistributable Library” packages.  These are for developers deploying applications on client systems that do not have our compiler and libraries installed.  The Runtime packages contain the Intel compiler runtime libraries needed by your dynamically linked application that you can redistribute along with your application.

 

In addition to providing our compilers in Toolkits and Standalone Component packages, users with active support can download toolkits and compilers from the Intel® Registration Center, “IRC”. IRC provides downloads for all past supported versions to which you are entitled with Intel® Premier Support.  And to add to all these methods, we also provide compilers and tools in popular package managers such as DNF and APT.  Supported package managers are also listed on the Single Component Downloads and Runtime Versions page.

 

oneAPI Packages and Compilers

Each oneAPI release or update has a version number for that release.  We use version numbering:

<major>.<minor>.<patch>

Where

<major> was “2021” for the 2021 releases, “2022” for the 2022 releases, 2023 for the 2023 releases

<minor> is used for the Update releases.  Update 1 will have <minor>=1, Update 2 <minor>=2

<patch> is usually “.0” unless we patch a <major>.<minor> version.  This is done, for example, for security fixes where the majority of the code is not changed from <major>.<minor> except for some critical fixes, security fixes for example.

Intel documentation often refers to the oneAPI package by the <major>.<minor> number, such as “2022.3” which was major version 2022 and minor version 3 and no patches.  You may also see this as “2022.3.0”.  

Patches:  If we do patch a released version, we will re-release FULL packages.  We do not have “patch kits” that update an existing version in-place.  No, we rebuild everything a release a full installer packages.  A patch updates the <patch> number.  For example, if we patch 2022.3.0, the new full package will be version 2022.3.1

oneAPI Package Versioning for 2023

The 2023 major release took major version “2023”.  As you would expect, the oneAPI 2023 inital release package started with minor version “0”.  And as you would expect, 2023 Update 1 took minor version ".1".  Therefore, the initial oneAPI packages for calendar year 2023 started at version 2023.0.0.  And the first 2023 update release, Update 1, had version 2023.1.0.  This matches the compiler version to the oneAPI package releases. That is, Intel®Fortran Compiler (ifx) and Intel® DPC++/C++ Compiler (icx, dpcpp) started at version 2023.0.0 which matched the oneAPI version.  The Intel® Compiler Classic compiler versions for calendar year 2023 will stay at major version 2021.

oneAPI Package Versioning for 2021 and 2022

<minor> for versions 2021 and 2022 is where it gets interesting.  For both major versions 2021 and 2022 the initial release oneAPI package minor version was not “.0” as you would expect.  No, it was “.1” for the initial release.  The minor version for Update 1 was “.2”, and Update 2 was “.3”.  Remember, this is for the overall oneAPI PACKAGE, not for the compilers contained in those packages.  Compiler version number started with a minor number 0, as you would expect.  So the initial release of the oneAPI package was 2022.1 and it contained compiler version 2022.0.0 

oneAPI Download Package Naming

 

You may notice addition letters and numbering on the names of the download packages.  For example, you may see download package names similar to:

  • Toolkits
    • w_HPCKit_p_2022.3.0.9564_offline.exe
    • l_HPCKit_p_2022.3.0.8751_offline.sh
  • Standalone Component Downloads
    • w_dpcpp-cpp-compiler_p_2022.2.0.9569_offline.exe
    • l_fortran-compiler_p_2022.2.0.8773_offline.sh

The letter at the front of a package name is for the OS.  Pretty obvious “l” linux, “w” Windows, “m” macOS. 

Then the name of the Toolkit or Component, “_p_” for “product”.  If and when we run a beta program, the package name will include “_b_” or have “beta” in the name.

Then <major>.<minor>.<update>.<build>  We discussed <major>.<minor>.<update> already.  <build> is not of much interest to a user.  Internally we use it for our product creation or build process.  When we start our build and test cycle for a release we may create several candidate packages.  Each build adds more fixes for things we discover as we build and test the upcoming release package.  To keep track of these iterations of builds we internally use these build numbers.  Users can ignore this number, major+minor+update is all you need to identify your product.

Then an optional “_offline” name for the offline package that contains all the binaries needed for that package.  Without “_offline” in the name indicates that the package is an online installer that will prompt for components first and then download the needed binaries.

 

Compiler versions for Compiler Classic and LLVM-based compilers and why they are not the same as the package versions

 

In the last section I described oneAPI Package versioning.  Within a package we have “components”.  Components are individual tools.  Like Fortran Compilers or C++ Compilers, or Vtune, or MKL.  Each is a component in a oneAPI package.  Now what confuses many users – Components have their own versions within the package.  So a oneAPI 2022.3.0 package may have an IFORT component at version 2021.7.0.  The component development teams create their own component versions.  You will see that the Component Versions do not match the Package Version in which they are provided.

 

The compiler uses its own versioning and we started IFX, ICX and DPCPP at v2022.0.0 with the initial release in the oneAPI Product 2022.1.  The Compiler Development team like to think we made the right decision based on semantic versioning standards. And to us it makes sense:  the initial compiler version for 2022 was v2022.0.0.  With Update 1 our compiler version was “2022.1.0”.  Compiler Update 2 was, logically, 2022.2.0 whereas the oneapi package for Update 2 was 2022.3.0.

 

Classic Compilers:  At this point you may be saying “wait: the Classic Compilers, IFORT and ICC, are still at version 2021.x.y!”.  Good observation.  Why are the Classic Compilers still at major version 2021?  The reason is ICC.  As you may know, our Intel® C/C++ Compiler Classic, better known as ICC, was deprecated recently (read the notice).  When it was time to build the 2022 versions of ICC and IFORT there were no major changes to ICC since version 2021.x; no major new features went into the ICC version released in calendar year 2022.  The C++ team has a solid replacement for ICC in the ICX compiler.  So the decision was to keep ICC's major version v2021.

 

You will notice that the compiler-only package filenames, not the Toolkit names, are the COMPILER version, not the oneAPI version.  Furthermore, the version is the version of the LLVM-based compilers and not the Classic Compilers.  This is especially confusing for macOS users - the Intel Compilers for macOS are the Classic Compilers, not the LLVM-based compilers.  For macOS only the Classic Compilers are provided.  Hence, you may expect the Versions and package names of the downloads to be those of Classic for macOS, but this is not so.  Due to our build system automation we use the same LLVM-based version name for the packaging of all 3 OSes, hence the macOS download package filenames carries the LLVM-based version name in the name of the package.  This may be confusing.

 

For the Intel® Fortran Compiler Classic, IFORT,  there was a different story.  IFORT and our new IFX compiler use the majority of code in our language parser (the Fortran Front End ). So with the calendar year 2022 release there were major changes, which normally would dictate a version bump to version 2022. However … due to our installation directory structure BOTH Classic Compilers must have the same version, due to a ‘latest’ symbolic link used to point to the latest version of BOTH compilers. It’s shared between ICC and IFORT.  So, we had to version both IFORT and ICC the same – would that be v2022 or v2021?  The decision was to use v2021 because we could not claim any major changes in ICC.  Since there is no new major activity in ICC development at this time, only security and minor bug fixes, you can expect the Classic Compilers to stay at v2021 for the remainder of their life cycles (which is another blog on the future of IFORT and ICC).

 

One final note on compiler packages:  The Classic Compilers are packaged along with the new LLVM-based compilers.  You cannot get just the LLVM-based compiler, or just the Classic compiler in it’s own package.  We package them as a pair so that users have choice, and can fallback to the Classic compiler if they run into an issue with the newer LLVM-based compiler. 

Stand-alone Compiler “Component” Download versions

If you download the Intel® Compilers from the Single Component Downloads and Runtime Versions page you will see that the versions listed for the compiler and compiler runtime downloads are the COMPILER version, not the oneAPI package version.  Again, to map between Compiler Versions and oneAPI Versions you should review and bookmark the Intel® oneAPI Toolkit Version to Compiler Version Mapping page.

 

 

Author! Author!

 

Keep up with all the latest from the Intel Fortran team by following me on Twitter @iCompilersRon

Ron Green #IAmIntel

rwg_scottsdale2021-small.jpg

Ron Green is a member of the Intel Fortran development team and moderator of the Intel Fortran Community Forum.  He has extensive experience as a Fortran developer and consultant in HPC for the past 30+ years and has been with Intel’s compiler team for 15+ years.  His technical interest area is in parallel application development with a focus on Fortran programming.  

 

Tags (1)
About the Author
Compilers, HPC, Developer Tools support. Fortran friendly.
2 Comments
msz59
Novice

Thanks for the explanation. The things, however, seem to be more complicated. The Intel® oneAPI Toolkit Version to Compiler Version Mapping page that you recommend shows the `ifort` compiler version to be 2.6.x for oneAPI Package Version 2022.2 and 2.7.x for 2022.3, respectively.

I have just downloaded 2022.2.1 version of "Intel Fortran Compiler Classic for macOS", dated Nov 1st, 2022 which appears to be the latest on Single Component Downloads and Runtime Versions page (I could not find 2022.3 there). And the installed `ifort` reports version 2.7.1.

regards, Michal

Ron_Green
Moderator

@msz59 that is a great observation on the article.

The compiler package names take on the version of the new LLVM compiler. This makes it eaiser for automation across the packages for all 3 OSes. For macOS this is confusing, since there is no LLVM compiler.  Logically, as you point out, the macOS package SHOULD use the Classic version.  But again, the scripts that build the tools are simplistic and take a since versioning string for the base name of the package irregardless of OS target.  I will update the article to include this information.

Thank you for finding this oversight in this article.

 

Ron