Moving to C++11 (again)


#21

C++11 is not a problem for PyStan! Here’s the fine print:

Supporting PyStan on Windows means compiling Stan with Microsoft Visual
Studio 2015. Here’s the list of C++11 and C++14 features supported:
https://msdn.microsoft.com/en-us/library/hh567368.aspx

  • C++11 is supported
  • C++14 has some support. Missing are Variable templates, Extended
    constexpr, NSDMIs for aggregates, Avoiding/fusing allocations,
    [[deprecated]] attributes.
  • C++17 (proposed) has minimal support, only Removing trigraphs,
    await/resume.

I hope the unsupported C++14 features aren’t features you were planning
on using. I don’t think Python on Windows is going to shift away from
Visual Studio 2015 for some time.


#22

Are there Python users using MSVC versions earlier than 2015?

MSVC 2015 is listed as only missing SFINAE for expressions. I think we can live without that if no code we import from Boost or Eigen uses it. No idea how many compiler headaches we’ll have of the kind we keep running into on Windows (not enough memory, bombing linkers, different sizes and features than clang++ and g++, etc.)


#23

There are no PyStan users using MSVC versions earlier than Visual Studio
2015.

Details about what’s supported on Windows is here:
http://pystan.readthedocs.io/en/latest/windows.html


#24

The extended constant expressions could have been really useful in some of the metaprogramming, but might be able to work around it.


#25

I may have misoverestimated that. Windows downloads of StanHeaders since R 3.3.0 was released look like
2.11.1 6
2.12.0 1
2.12.2 3
2.13.0 2
2.13.1 3
2.13.2 1
2.14.0 5
2.14.1 2
2.14.2 4
2.15.0 17
2.15.1 15
2.15.2 9
2.15.3 36
3.0.0 15
3.0.1 63
3.0.2 151
3.0.3 57
3.1.0 172
3.1.1 330
3.1.2 572
3.1.3 388
3.2.0 436
3.2.1 560
3.2.2 1884
3.2.3 2412
3.2.4 1312
3.2.5 1700
3.3.0 4307
3.3.1 13711
3.3.2 5275
3.4.0 143


#26

These are stats from RStudio’s servers? How easy is it for pre-3.2 users to get to that server? I didn’t trust the “0-cloud” option for the longest time because I didn’t know where that went.


#27

Yeah. 3.2 users could access it via http rather than https.


#28

The move to C++11 (and one or two features of C++14) begins!

I made a wiki page to track what compilers we imagine we’re targeting and what features we’ve determined they all support here: https://github.com/stan-dev/stan/wiki/Supported-C---Compilers-and-Language-Features


#29

This is super exciting even though I can’t be there for the c++11-a-thon!


#30

@Bob_Carpenter started putting up some relevant issues on GitHub, https://github.com/stan-dev/stan/issues?q=is%3Aissue+is%3Aopen+label%3AC%2B%2B11 and https://github.com/stan-dev/math/issues/541.

@Bob_Carpenter will also add Eigen 3.3 to math tonight and tomorrow we’ll play around with compiling it against C++11. The hope is that the move semantics will kick in and we’ll see some significant performance boosts.

Other immediate fixes that we can implement include

  • Using static_assert to give informative error messages to our template meta programs.
  • Use auto and decltype to clean up the densities, although we may want to wait for operations and partials to be rewritten so we only have to update each density once.
  • Implementing some metaprograms as constexpr .
  • Implementing some metaprograms as variadic template functions.
  • Use delegating constructors to reduce code duplication or auxiliary init functions.
  • Use in class member initializers to simplify constructors.

Longer term goals include

  • Multithreading chains.
  • Generalizing functors to use std::function and the possibility of closures for some of our functionals.

I think that was most of it – please add new items if I forgot anything.


#31

Still working on that. It busted LLT for forward-mode. I’m making sure that’s the only problem before trying to dive in and fix it. I think it is having mixed type issues in the internals. Also, I’d like to add:

  • using bind and lambdas to create test functors
  • using std::function for the arguments to functionals

We definitely want to use those initializers and delgating constructors everywhere. As we discussed at the C++11 meeting today, I don’t know if that’s better to stage by module (like mcmc) or by type of change. I think we don’t have to really decide—we’ll just keep doing these things until we hit a fixed point.


#32

Thanks for starting on the path. Sorry I missed out on today. I’ll probably miss out on tomorrow too, but I think I’ll catch up just fine.

For those that missed it, this is from Bob:

This is a good overview:

http://blog.smartbear.com/c-plus-plus/the-biggest-changes-in-c11-and-why-you-should-care/

I think pretty much everything is going to be useful!
We have our refactoring work cut out for us. Soooo much is
going to be able to be simplified with this.


#33

OK, 11 PM and I think I have all the tests working for Eigen 3.3.3 with all the g++ versions past 4.9 we’ve been having trouble with. Pull request coming as soon as test-headers passes. I lost all the doc for fvar I added with the last pull req. I’ll bring that in later rather than fussing with it now.

Last hurdle was calling gcc rather than g++, which works fine until you get to the linker.

@wds15 brought up the issue of whether we’d go past g++ 4.8 support, which is apparently what they have on clusters. No idea how common that is elsewhere. He mentioned that it covers all of C++11 but not all of C++14. No idea how it compares to MSVC.


#34

The other thing I was mentioning in the meeting was std::vector::emplace_back. It combines push_back and construction and is the way to add new members to a vector.


#35

https://gcc.gnu.org/gcc-4.8/cxx0x_status.html


#36

For more detail, https://gcc.gnu.org/projects/cxx-status.html#cxx11.


#37

Is it safe to use C++11 stuff yet (specifically default template parameters for functions)? I have something that would be vastly easier with C++11.


#38

Yes, are agreed that C++11 is okay going forwards. Unless there was some misunderstanding and anyone wanted to object?


#39

It is certainly safe on a branch. I think there is an open question of whether we should do a small release now-ish to fix the problems with the messages not being displayed when the chains cannot be initialized, the chain numbers not appearing in the output, etc. If so, we should do that before putting any C++11/14 stuff in.


#40

@bgoodri: That sounds like a good idea. Let’s do a patch release first. There are a bunch of bugs we can probably knock off in the next couple weeks and some behavior like transformed data RNG inits we can sort out.