Alpaka: Discussion: Reduce legacy support / future support

[j-stephan]

In today's alpaka VC we raised the question of dropping some legacy stuff in favour of C++17 some time after the next release. We currently aim to do this by mid-2021. However, this might affect some of our users outside of HZDR who are hereby invited to participate in this discussion. @fwyzard, @bertwesarg and the DLR come to mind, but everyone should feel free to notify other non-HZDR alpaka users they know of.

Current candidates for removal are (feel free to expand this list):

• old CUDA versions (everything older than CUDA 10, maybe CUDA 10 as well, point releases that are not the latest versions)
• old MSVC versions (everything older than the latest stable version)

Things to consider:

• Will this seriously break existing workflows?
• Will (older) HPC systems no longer be supported?

Another question that was raised today is if we want to support Apple's future ARM-based products. Right now we have no developers / users (that I know of) who could help us.

[fwyzard]

Thanks for the heads up.
CMS is already using c++17, CUDA 11 and gcc 8 or later - so I think we should be fine.

[j-stephan]

DLR responded per mail:

• They don't care about MSVC
• They require CUDA 10.x but don't care about older releases
• They wouldn't like a full transition to C++17 because this affects their users who still work with older codes.

[bernhardmgruber]

DLR responded per mail:

• They wouldn't like a full transition to C++17 because this affects their users who still work with older codes.

That statement is a bit vague. Does that mean we need to stick with C++14 fully? Or are they just afraid of C++17? Do they tolerate some C++17 features?

• They require CUDA 10.x but don't care about older releases

That kind of binds us to C++14 when compiled with nvcc.

Could you still please ask them for a minimum host compiler version they would like to suport? Thank you!

[j-stephan]

That statement is a bit vague. Does that mean we need to stick with C++14 fully? Or are they just afraid of C++17? Do they tolerate some C++17 features?

Translation of the sentence in question (original in German):

The switch to C++17 is more critical. We wouldn't want this so soon because of alpaka's header-only concept. This would cascade through to our users.

Sounds like a hard C++14 limit to me.

Could you still please ask them for a minimum host compiler version they would like to suport? Thank you!

Will do.

[j-stephan]

DLR responded. They require compatibility for:

• CUDA 10.2.89
• CUDA 10.1.105
• gcc >= 5.5.0
• clang >= 3.9.1
• icpc >= 2019.0

[BenjaminW3]

We dropped support for clang 3.9 a long time ago. So we can not fulfill this already.
Besides from that, it looks like we can drop CUDA 9.

What is the state of support for newer CMake versions? It should not be that hard to update this one. We might require CMake-3.18+ in the future when we got the native CMake CUDA support working completely.

[j-stephan]

Another interaction with DLR:

• Despite us not officially supporting clang 3.9, they still manage to build their alpaka-based software with this compiler, even the latest release.
• They are not certain that their users are going to switch to C++17 soon. They won't be able to support GCC 8.x and clang 10.x in the near future (which have full support for C++17), but GCC 7.x and clang 6.x look more promising. I'll check again if they'd be okay with us removing any compilers older than GCC 7.x / clang 6.x.
• CUDA 10.1.105 is a current hard limit with no immediate update plan.

[sbastrakov]

Nice, thanks for keeping tabs on that.

[j-stephan]

My contact at DLR asked around their user base and gave me this list of hard version limits for the foreseeable future:

• GCC 7.x
• clang 5.x
• ICPC 2019.x
• CUDA 9.2

So the requested compiler versions were lowered a bit. This means we could get rid of supporting GCC 5 and 6 as well as clang 4. Still a long way to C++17 I'm afraid.

[j-stephan]

We now have an interesting conflict of interests: The current SYCL specification demands C++17 or later:

https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:normativerefs

@SimeonEhrig kindly pointed this out.

[j-stephan]

I wonder if we should turn the current alpaka release into a long-time support version (bugfixes, but no new features) and switch to C++17 in the next release.

[sbastrakov]

There can also be a compromise (although not necessarily a good one, but as an option).

Write alpaka code such that it compiles and works with both C++14 and C++17 - I think we should be making C++17 not break even with only supporting C++14. Then the SYCL backend is written for C++17 only and conditionally enabled. So a user can use SYCL only with C++17, and otherwise alpaka with both 14 and 17 as they choose.

[SimeonEhrig]

There can also be a compromise (although not necessarily a good one, but as an option).

Write alpaka code such that it compiles and works with both C++14 and C++17 - I think we should be making C++17 not break even with only supporting C++14. Then the SYCL backend is written for C++17 only and conditionally enabled. So a user can use SYCL only with C++17, and otherwise alpaka with both 14 and 17 as they choose.

I had a similar idea. But Jan's idea sounds also interesting. I think, we should think about, what are the benefits, if we can use C++ 17, because I think in the end, there is the question, what occurs less work: supporting a LTS version and use the benefits of C++ 17 for future development or still supporting C++ 14 and enable the Sycl backend only, if C++ 17 is enabled.