It seems like C++11 threading is not supported in Xcode 7.x and earlier, but we’d like to allow it to be used for multi-core same-machine parallelism in a pretty exciting way, and ideally without a ton of ifdefs littering the code. One way of limiting ifdefs I have proposed in another thread, but we would also like to consider dropping support for these strange compilers. Xcode 8 was released September 13, 2016, which is not so long ago. Through some ineffable quirk of Apple’s, they removed C++11 threading support from their version of the compiler, but it is present in much older versions of vanilla clang, which Mac users are also able to install through a variety of means (though none as easy as xcode-select --install).
I’d like to use this thread to see if anyone has a use-case where they must use Xcode < 8, and generally collect people’s thoughts about this potential change.
I would be in favor to require thread_local capable compilers only in going forward (its vanilla C++11 after all).
The problem with making threading stuff optional is that anything which uses threads in Stan will have to be coded up for the serial and for the thread case which is very resource intensive on us developers.
I have managed to get g++ and clang++ in recent enough versions to compile everything. That covers the majority of our users I think.
I would agree that people should not be using old versions of Xcode for various reasons, but a lot of this depends on what the definition of is is. Really, C++14 is required, except that only means that the compiler has to accept the -std=c++14 or -std=c++1y flag (which older versions of Xcode clang do). The compiler that comes with Rtools implements most but not all of the C++14 standard and different versions of MSVC have varying degrees of implementation of the C++14 standard. So, if the only problem was that Apple’s clang didn’t implement thread_local until recently, I would say that Stan should still work (without threading) with it. But there are other problems with it and it is easy enough to get a newer version of Xcode or to install clang4 from CRAN.
What are some other problems? I forget / not sure if I heard about them. I think the stuff we are allowing ourselves to use according to our wiki and CI setup works with old (pre Sep 2016 or whatever) Apple Clangs.
It is closed source, so no one except Apple knows what it is really doing. It does not support openMP. The whole XCode is a huge thing to download and install if you only need part of it. Things like that.
The CLI is more minimal tho, and seemingly required for even the RTools thing above. But those other two + threading seem like good reasons to switch from recommending it. I just wonder about the upgrade path. And I dream of having our own installer that packages the latest clang et al internally with no PATH variables, etc required.
Yeah, I would agree with C++11 being required so we just do that. However, at the meeting we decided to make the threading thing by default turned off with the rationale
of not hurting users on old compilers
making sure that there is for sure 0 performance hit due to this change
To my understanding we would revisit this decision once we have solid performance benchmarks to answer point 2 with confidence. There is nothing we can do about point 1 other than waiting.
These are all great reasons to recommend an alternative. I can add the annoying need to click through licenses and enable command-line tools, which trip lots of people up. And the tie to specific versions of the OS, which seems completely unecessary.
We decided (to the extent we ever decide anyting), that our code could use anything supported by the recommended Rtools compiler. So I think we should require things that support the same functionality.