Project

General

Profile

Task #2012

Bump required version numbers of infrastructure for 2018

Added by Mark Abraham about 3 years ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
build system
Target version:
Difficulty:
uncategorized
Close

Description

For GROMACS 2017, we should choose some new minimum supported versions to target, remembering that they start being relevant to users when we release in 2017. Remember, there is a trade-off between what new things we can do (because we support a smaller range of things) vs what things we might require some users to do (because GROMACS no longer builds out of the box for them). Your workload as a GROMACS developer goes up for each extra version we support, even if that only shows up in what you have to do to keep Jenkins happy, or how hard it is for you to get access to others' feedback because they are thinking about something that is mysteriously broken in some Jenkins combination. Also, versions that may or may not be the bases for forks that support hardware that GROMACS users might have that isn't already shipping in early 2017 really shouldn't factor highly. The statements below are true in July 2016.

CMake
-----

We currently require >= 2.8.8. CMake does offer binary downloads on their webpage, and a source build is trivial (even though we'd prefer a GROMACS user have to do neither). Relevant discussion from LLVM that considered bumping their requirement recently at http://lists.llvm.org/pipermail/llvm-dev/2016-April/098814.html - they went with requiring 3.4.3. Relevant distros and their versions are:
  • CentOS7 (and thus RHEL7, ScientificLinux and others) -> 2.8.11. (But Fedora EPEL is intended to augment these ultra-conservative distros, and has 3.5.2)
  • Ubuntu Wily -> 3.2.2 (but will be out of support before we release)
  • Ubuntu Xenial LTS -> 3.5.1
  • Ubuntu Yakkety -> 3.5.1
  • Debian jessie -> 3.0.2 (but there's ppas and Ubuntu is a lot more popular)
  • Debian stretch -> 3.5.1
  • Debian sid -> 3.5.2
  • FreeBSD 10.2 -> 3.5.0
  • FreeBSD HEAD -> 3.5.2
  • Fedora 24 -> 3.5.2
    Rolling or source distros will be ahead of whatever we require, so don't matter (Gentoo, Arch, macports, homebrew)

CMake has been acquiring more support for generator expressions and better external project builds over a long time, so there are useful things there throughout (particularly as we are now bundling quite a few things, and may consider more). We have quite a few workarounds and hacks documented as able to go away when we get up through 2.8.10/11/12. Other highlights: 3.0 acquired support for find_dependency to work with find_package(). 3.1 acquired support for targets to require particular C/C++ standards. 3.2 try_compile() now honors linker flags, and try_run() honours LINK_LIBRARIES (testing such things will work well later is a recurring problem for us). 3.3 finds static libcuda by default. 3.4 didn't seem to have much. 3.5 adds clang support for FindOpenMP.

So in terms of widespread availability, anything up to 3.5.0 is plausible. The only killer feature looks like C++11 compiler feature support in 3.1. The last release from 3.4 series (ie 3.4.3) would likely be a good compromise on bugs vs stability.

gcc
---

We currently require >= 4.6, which mostly supports C++11, and permits us to continue to support CUDA 5.0. It lacks user-defined literals (4.7), delegating constructors (4.7), alignas (4.8), inheriting constructors (4.8), all of which would occasionally be convenient for us. gcc claims full support for C++11 in 4.8.1. Performance on AVX got a lot better in 4.7 (and 4.8? I forget). 4.8.1 was released May 31, 2013, so will have been out for four years by the time we ship GROMACS 2017.

CUDA
----
We currently require >= 5.0 on Linux and >= 8.0 on Windows (a limitation based on needing MSVC 2016). CUDA started getting some C++11 support in 6.5, and unofficially it works in 7.0 and is formally supported in 7.5. Requiring gcc 4.7 would require CUDA 5.5, requiring gcc 4.8.1 would require CUDA 6.0. If we want to get serious about extern-template-based short-range kernels so we can have lots of new development capabilities, then the safest move would be to require 7.5, which will have been out for two years by the time we release GROMACS 2017. (If so, we probably need to bump to OpenCL 2.0 also.) We could bump to say 6.5 in the short term, and once CPU SIMD kernels are using extern templates, decide whether to bite that 7.5 bullet, or not.

OpenCL 1.1, icc 16 and msvc 2016 are probably ok to keep as minimum requirements. clang we could require 3.9 because that finally has openmp supported by default. But performance is probably not so interesting. Anything else?


Related issues

Related to GROMACS - Task #2505: increase cmake reqirement for GROMACS 2020Closed
Related to GROMACS - Task #2831: Bump required version numbers of infrastructure for 2020New

Associated revisions

Revision 82e7490a (diff)
Added by Erik Lindahl about 3 years ago

Bump oldest cmake, compiler and CUDA versions required

For release 2017 we now require gcc-4.8.1, clang-3.3 and icc-15, so we
can rely on full C++11 support. We now also require CUDA-6.5 and
CMake-3.4.3. This in turn means we can remove some older cmake tests,
and since many users won't read the install guide there are now
version tests that produce fatal errors during CMake configuration for
compiler versions we know are too old.

Various hacks and workarounds in source and build system can
now be removed.

Fixed error in previous definition of GMX_ALIGNED

Updated C++11 compatibility tests in line with code we are now using.

Fixed that hwloc includes were not treated as system headers.

Treated including thread-MPI and TNG header files as system paths, to
be consistent with how we'd treat them if we were using external
versions of these.

Fixed icc 16 warnings in lapack routines.

Fixes #2012.

Change-Id: I36e02379a985b22c72f0f06481c65cae6e780c02

History

#1 Updated by Mark Abraham about 3 years ago

Mark thinks we should require

cmake 3.4.3
gcc 4.8.1
cuda 6.5 in the short term, then see how extern templates are working before considering 7.0 or 7.5

#2 Updated by Mark Abraham about 3 years ago

  • Description updated (diff)

#3 Updated by Szilárd Páll about 3 years ago

CMake: Ubuntu Trusty (14.04) is supported until 2019, but given that it comes with 2.8.12, I guess that's one case where users will have to install new CMake.
Static libcuda issue does not seem overly relevant, so if there are objections, 3.2 may be good enough.

gcc: as new as possible, more than 4.8 might be a pain for users, >4.9 may not be more pain except for CUDA 6.5.

CUDA: agree with the above.

#4 Updated by Erik Lindahl about 3 years ago

Yeah, I think it's acceptable that a user might have to install a slightly newer version of gcc than the default if they absolutely need to use a LTS distro that will be almost 3.5 years old when Gromacs 2017 comes out, so I'm all for requiring gcc-4.8.1.

Likewise, if LLVM requires 3.4.3, I think we should go with that too. In general (when possible) I prefer to do larger version bumps more infrequently rather than a minor bump for every new release.

Note that there is still no newer version of Cuda on ARM than 7.0, so requiring 7.5 would mean dropping ARM support until NVIDIA updates it.

#5 Updated by Gerrit Code Review Bot about 3 years ago

Gerrit received a related patchset '1' for Issue #2012.
Uploader: Erik Lindahl ()
Change-Id: I36e02379a985b22c72f0f06481c65cae6e780c02
Gerrit URL: https://gerrit.gromacs.org/6073

#6 Updated by Mark Abraham about 3 years ago

Yes, good point, Trusty will need users to update cmake for any of the proposed required versions. It will be three years old, so isn't the end of the world as constraints upon users go

#7 Updated by Szilárd Páll about 3 years ago

I don't advocate sticking to an older CMake (or gcc), but I'd note for the record, that the above reasoning seems to be biased towards user-maintained workstation installs that have shorter shelf-life (hinting that 3.5 years old installs is somehow outdated?).

A lifetime of 4+ years on clusters (in particular group/department mini-clusters but not only) is common and normal; OS installs are often done at delivery/setup and rarely reinstalled during the lifetime of the machines (even on most of our servers almost 4.5 years old OS).

So most will not have a 3.5+ years install because they "absolutely need" it, but simply because 3.5y is not a particularly old one, especially not since Ubuntu LTS enablement stack and similar software stacks keep things well supported for long.

I know cmake is not hard at all to install (nor is gcc), but it's not far-fetched to assume that most installations will not have a little more than 1 year old software already available (cmake 3.4.3 was released 26 Jan 2016). Putting extra burden on the maintainers/admins can delay adoption, so I'd be curious to know what fraction of users/admins would be willing to install CMake and CMake + gcc if that required before starting to use a new release (if there will be surveys in the future, it would be useful to ask).

#8 Updated by Mark Abraham about 3 years ago

Yes, it's fair to be curious, but to get actionable data you also have to ask them to evaluate that cost relative to the value they expect to get from the new version (e.g. people just installed CMake 2.8 for GROMACS 4.6 if they knew that was the only way they were getting GPU support), and the value they didn't get because the developers had to test and support more versions of CMake, and how many other software packages they install that also benefit from the fact that they maybe now have a PPA or EPEL set up. And I bet the answer to that is "uh, that's hard, I dunno" ;-)

If the cluster/server is only running GROMACS, then an hour or two of sysadmin ~once a year installing new stuff is not a high price to pay for getting higher utility from that hardware. And of course not everyone installs or adopts new versions of GROMACS immediately, so the effective average age of infrastructure upon which people will want to install GROMACS 2017 is even more murky. Bundling a bootstrap of cmake is an option if someone wants to go there ;-)

#9 Updated by Szilárd Páll about 3 years ago

Mark Abraham wrote:

Yes, it's fair to be curious, but to get actionable data you also have to ask them to evaluate that cost relative to the value they expect to get from the new version (e.g. people just installed CMake 2.8 for GROMACS 4.6 if they knew that was the only way they were getting GPU support), and the value they didn't get because the developers had to test and support more versions of CMake, and how many other software packages they install that also benefit from the fact that they maybe now have a PPA or EPEL set up. And I bet the answer to that is "uh, that's hard, I dunno" ;-)

Fair points, but admins likely gain little from a new GROMACS release (and may even consider them a loss of time depending on the effort required). Extra repos are not a robust way to manage machines with multiple software/versions installed, so the PPA/EPEL are an option but, again, this only applies to workstations (or dedicated nodes) with less software to manage.

However, if we'd avoid mixing use-cases, quite clear questions could be asked about the efforts e.g.
  • users would find acceptable to install on machines they manage e.g. workstations
  • users think the staff of their dedicated resources would find acceptable
  • staff of shared resources like HPC clusters would find acceptable.

If the cluster/server is only running GROMACS, then an hour or two of sysadmin ~once a year installing new stuff is not a high price to pay for getting higher utility from that hardware.

Certainly! If the machines are dedicated, software (and staff resources) will be dedicated, so the picture is much more simple.

However, how many users fall in the dedicated workstation/mini-cluster category is quite hard to know, isn't it? If users are on the path of abandoning traditional HPC and do most of their work (sim & analysis) on dedicated local resources, possibly even more aggressive upgrades (especially for stuff like CUDA) could be reasonable!

And of course not everyone installs or adopts new versions of GROMACS immediately, so the effective average age of infrastructure upon which people will want to install GROMACS 2017 is even more murky. Bundling a bootstrap of cmake is an option if someone wants to go there ;-)

Indeed, it is, but I'm not sure how much effort is that and whether any would be up for the challenge. Do you know of projects that bundle cmake?

#10 Updated by Szilárd Páll about 3 years ago

I'd like to note that C++11 + CUDA issue could be made a bit more manageable by converting host code to cpp and compiling it wth the regular C++ compiler. I'm in the process of double-checking, but from what I heard this is possible is the kernel launch language extension is replaced with cudaLaunchKernel (supported with CUDA >=v7.0), the right runtime headers are included, and for linking the CUDA host + kernel code nvcc is used. This may or may not be substantial amount of complexity in the build system. I'll report back when I know more.

#11 Updated by Erik Lindahl about 3 years ago

  • Status changed from New to Resolved

#12 Updated by Mark Abraham about 3 years ago

Leaving this issue open until we decide if/when we're doing another user survey.

Upon reflection, I think the only sane path in supporting distros like centos is to document and expect the use of devtoolset (but e.g. permit stuff from local modules).

#13 Updated by Szilárd Páll about 3 years ago

Szilárd Páll wrote:

I'd like to note that C++11 + CUDA issue could be made a bit more manageable by converting host code to cpp and compiling it wth the regular C++ compiler. I'm in the process of double-checking, but from what I heard this is possible is the kernel launch language extension is replaced with cudaLaunchKernel (supported with CUDA >=v7.0), the right runtime headers are included, and for linking the CUDA host + kernel code nvcc is used. This may or may not be substantial amount of complexity in the build system. I'll report back when I know more.

I was wrong, nvcc manages the context, kernel, modules, etc. automatically by generating the appropriate biolerplate code. The only way to avoid nvcc compilation of host code is to use the more verbose driver API (which is similar to OpenCL).

#14 Updated by Mark Abraham over 2 years ago

There has finally been a new release of GoogleTest. We don't need to bump our bundled version for 2017, but I have a patch that updates it (to be submitted in future), because it has a few nice things I'd like to propose using.

#15 Updated by Mark Abraham over 2 years ago

  • Status changed from Resolved to Closed

#16 Updated by Mark Abraham 12 months ago

  • Related to Task #2505: increase cmake reqirement for GROMACS 2020 added

#17 Updated by Mark Abraham 12 months ago

  • Subject changed from Bump required version numbers of infrastructure to Bump required version numbers of infrastructure for 2018

#18 Updated by Mark Abraham 9 months ago

  • Related to Task #2831: Bump required version numbers of infrastructure for 2020 added

Also available in: Atom PDF