Move up to C++17

[SteveBronder]

Description

Jw, what are the blockers that stop us from moving to C++17?

There's a couple features that I think would be nice. From here

• Nested namespace definitions, e.g., namespace X::Y { … } instead of namespace X { namespace Y { … } }
• Fold expressions, for variadic templates (ala std::is_arithmetic<Args> &&...)
• A compile-time static if with the form if constexpr(expression) (No more #ifdefs for the OpenCL code!)
• copy-initialization and direct-initialization of objects of type T from prvalue expressions of type T (ignoring top-level cv-qualifiers) shall result in no copy or move constructors from the prvalue expression.
• Additional mathematical special functions, including elliptic integrals and Bessel functions see here

From that same wiki page it looks like we would have to bump up the supported compiler versions?

GCC since version 7 has complete support for C++17. GCC C++ standards status
Clang 5 and later implement all the features of C++17. clang C++ standards status

Current Version:

v2.20.0

[SteveBronder]

Another reason is better support for devirtualization

I can run a branch to check the performance, but I think we can put a final over the chain methods

[andrjohns]

The main thing at the moment would probably be Windows, since that's restricted to the gcc version packaged with RTools, which is only 4.9.3 at the moment. Having said that, the next version of RTools will apparently ship with gcc 8 (https://cran.r-project.org/bin/windows/testing/rtools40.html)

[alashworth]

Devirtualization should be pretty well supported in C++11; there's nothing stopping you from adding final in 4.9.3, AFAIK.

[syclik]

Jw, what are the blockers that stop us from moving to C++17?

This is really a question about what are the blockers from requiring a higher version C++ compiler. Something to note: different versions of compilers support incomplete parts of the spec. For example, see C++ Standards Support in GCC.

Although, I think technically we (the developers of the Math library) could pick a version that's different than what's currently supported across Stan, we shouldn't do that lightly. Here are some of the things we care about:

1. users of the Stan interfaces are able to use Stan. That's RStan, PyStan, and CmdStan.
2. we are able to provide clear instructions on how to get a toolchain installed for these users
3. we are able to support users that are on Windows, Linux, and Mac.

If we wanted to change our requirements to say something like g++ 7, we would need to verify that rstan, pystan, cmdstan users could get it working on windows, mac, and linux. It'd require us knowing how to install g++ 7 on different platforms: that's been one of the limiting factors.

At some point, we have to leave a subset of users in the dust. For a long time, we supported g++ 4.2, but we had to move on in order to use C++11 and C++14 features. We're stuck on g++ 4.9 because it's hard to install a toolchain under Windows. If you can figure out how to install g++ 7 on Windows reliably and we can use that for RStan and PyStan, we could probably move the minimum requirements at that point.

[SteveBronder]

Devirtualization should be pretty well supported in C++11; there's nothing stopping you from adding final in 4.9.3, AFAIK.

Yep! I made a branch trying this on the chain methods, but sadly I really didn't see any speedups. Probably because we have a small inheritance structure

If we wanted to change our requirements to say something like g++ 7, we would need to verify that rstan, pystan, cmdstan users could get it working on windows, mac, and linux. It'd require us knowing how to install g++ 7 on different platforms: that's been one of the limiting factors.

I think this is blocked until Rtools40 comes out. pystan has conda and cmdstan can probably do whatever it currently does. Do we have a doc somewhere about this? The most I see is Stan maths windows dev notes

It looks like msys2 is the windows solutions?

At some point, we have to leave a subset of users in the dust. For a long time, we supported g++ 4.2, but we had to move on in order to use C++11 and C++14 features. We're stuck on g++ 4.9 because it's hard to install a toolchain under Windows. If you can figure out how to install g++ 7 on Windows reliably and we can use that for RStan and PyStan, we could probably move the minimum requirements at that point.

I think it's best to leave this open until Rtools40 comes out. Then we can make sure we are aligned with Ben on this

At some point, we have to leave a subset of users in the dust.

Tbh I've always wondered who these people are. Who has not updated their compiler in the last 12 years?

[rok-cesnovar]

Tbh I've always wondered who these people are. Who has not updated their compiler in the last 12 years?

I think that is mostly people that dont use a compiler outside of Stan. And those that run Stan on clusters not maintained by them.

[wds15]

Yes, we should be kind to those cluster users. On clusters it is hard to impossible to install a compiler. We should do some research on what the big distributions provide. The rhel which we use at work only brings a g++ 4.8 compiler as stock compiler. It was hard to convince IT to install a newer development compiler on our cluster.

So what do the large commercial distributions bring with them and what are common cloud images people can easily get up and running.

If we enforce that people must install compilers, then we will loose (some of) these users which run Stan for large scale problems...and we want to solve big stuff, don’t we?

[SteveBronder]

It's a super bummer that RHEL7 is stuck at gcc 4.8.x, but idt RHEL is a blocker here since we use c++14 and gcc didn't support that fully till gcc-5. So if people are using RHEL with Stan then they already added gcc 5 themselves right? If they can update to 5 then I'm not sure what the blocker is to update to 6, 7, or 8

https://gcc.gnu.org/projects/cxx-status.html

imo I think the only blocker here is waiting for rtools 40 to come out so it's easy to setup on windows

And like, meta, it's not that I care about C++17 that much, but I do care about C++20 and if we are ever going to be able to move up to 20 then moving to 17 first is probably a good idea. I think the nice update path here would be

1. Wait till rtools 40 comes out
2. For the Stan release after that tell people that in X (like 2 or something) releases we are going to move up to C++17
3. We can have the upstream packages check the compiler version of users to see if that will be an issue for them and if so give a little warning message
4. After X releases do the upgrade

[bob-carpenter]

We're limited by Rtools, but otherwise no reason not to upgrade as soon as possible in R.

…

On Nov 3, 2019, at 5:00 PM, Steve Bronder ***@***.***> wrote: It's a super bummer that RHEL7 is stuck at gcc 4.8.x, but idt RHEL is a blocker here since we use c++14 and gcc didn't support that fully till gcc-5. So if people are using RHEL with Stan then they already added gcc 5 themselves right? If they can update to 5 then I'm not sure what the blocker is to update to 6, 7, or 8 https://gcc.gnu.org/projects/cxx-status.html imo I think the only blocker here is waiting for rtools 40 to come out so it's easy to setup on windows And like, meta, it's not that I care about C++17 that much, but I do care about C++20 and if we are ever going to be able to move up to 20 then moving to 17 first is probably a good idea. I think the nice update path here would be • Wait till rtools 40 comes out • For the Stan release after that tell people that in X (like 2 or something) releases we are going to move up to C++17 • We can have the upstream packages check the compiler version of users to see if that will be an issue for them and if so give a little warning message • After X releases do the upgrade — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[wds15]

Rtools is about to do a huge jump in gcc versions. That's quite a change to say now we use the RTools windows as the defacto standard for all platforms (and not just for Windows).

We will loose users if we are too aggressive with bumping C++ standards too quickly.

[bgoodri]

I think we'll be fine with RStan in April, but I think @ariddell is reluctant to move PyStan to C++17.

[riddell-stan]

We lose the ability to ship "binary versions" of PyStan if we move to C++17 now. Binary versions ("wheels") mean that the package contains libraries pre-compiled for the relevant system. For users, having these wheels is really nice. It makes installation as fast as other packages in the same space (e.g., pymc).

Here's the most recent "platform" which we have to target on Linux if we want to build wheels: https://www.python.org/dev/peps/pep-0599/ . GCC 4.8.2 is the compiler.

I suspect that moving to C++17 would be possible within 12-36 months. Python moves relatively quickly on this.

Moreover, I do think keeping things to C++14 for a bit makes it easier for people in academia who have centrally-managed Linux servers. These servers almost always run RHEL or Centos. They tend to have older compilers.

[wds15]

I can only echo what @riddell-stan says! Asking users on clusters to deploy a compiler is a big call. On these clusters usually RHEL is running (and not necessarily the latest).

Keeping things working with RHEL (now at gcc 4.8.2) is a great plus for Stan. I know that this poses considerable restrictions on C++ and thus on developers, but the jump to more recent gcc versions should absolutely not be taken lightly (I am myself in the fortunate situation that IT is deploying now a g++ 8.2 compiler in the next production, which is great... but not standard at all).

[SteveBronder]

Looking into centos 7, does pystan also work with 2.7? I don't know much about this but from the thread below it looks like yum only works with 2.7?

https://www.centos.org/forums/viewtopic.php?t=70838

I'm fine with waiting a year, that also gives us a good enough amount of time to let users know about the plan to move up. If everyone is fine with the one year tag then we can put a notice up next release saying, "In 4 releases (one year) stan math will be moving up to the C++17 standard"

[bgoodri]

It seems like there are a few things that are outside of our control, but it is perhaps a good goal to try to move to C++17 sometime in 2021. But according to https://en.cppreference.com/w/cpp/compiler_support NVIDIA nvcc has not done anything with C++17. Is that going to be an issue for people who want to use NVIDIA GPUs?

…

On Sun, Nov 24, 2019 at 2:23 PM Steve Bronder ***@***.***> wrote: Looking into centos 7, does pystan also work with 2.7? I don't know much about this but from the thread below it looks like yum only works with 2.7? https://www.centos.org/forums/viewtopic.php?t=70838 I'm fine with waiting a year, that also gives us a good enough amount of time to let users know about the plan to move up. If everyone is fine with the one year tag then we can put a notice up next release saying, "In 4 releases (one year) stan math will be moving up to the C++17 standard" — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1300?email_source=notifications&email_token=AAZ2XKV3TT624CXBDHD2HRLQVLIDJA5CNFSM4IJJSR7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFASZLQ#issuecomment-557919406>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKT6HLQJS2C5BFEKU3LQVLIDJANCNFSM4IJJSR7A> .