These are chat archives for symengine/symengine

29th
Jul 2016
Isuru Fernando
@isuruf
Jul 29 2016 02:24
@bluescarni, is there a thread local storage mechanism that is supported by all of the compilers that we use? thread_local doesn't seem to be supported by appleclang
Francesco Biscani
@bluescarni
Jul 29 2016 09:12
@isuruf appleclang is different from homebrew clang right?
my understanding is that thread_local is finally being added in the latest versions of Xcode: http://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports
I looked at alternatives a few days ago: there is boost's thread local storage, but a big caveat with it is that if you are not using boost threads (e.g., you are using std::thread) then the thread-local storage might not be freed upon thread completion
for piranha I just decided to require a thread_local capable compiler
Francesco Biscani
@bluescarni
Jul 29 2016 09:17
would this be a problem for symengine? I am starting to use thread_local in a separate branch, but I can still probably work-around missing thread_local implementation
Isuru Fernando
@isuruf
Jul 29 2016 09:28
It seems even MSVC support thread_local. Appleclang doesn't support it right? Does it support C version _Thread_local?
Francesco Biscani
@bluescarni
Jul 29 2016 09:28
it does support some type of C-like thread-local storage , not sure if that's the correct keyword though
but it's useless for C++ classes, as it will not call the object's constructor/destructor
it works only for POD types
Isuru Fernando
@isuruf
Jul 29 2016 09:29
Yes, I asked because I wanted to use it for some strings. (I can use a big enough char array)
Francesco Biscani
@bluescarni
Jul 29 2016 09:31
that should work. I would tentatively guess the syntax is probably compatible with GCC's (meaning the keyword would be __thread)
The only holdout has been support for the thread-local keyword. This year, we added support. Let me tell you a little about it. If a variable is declared with a thread-local keyword, LLVM creates a separate variable per thread.
Initializers are called before the first use after thread entry, and destructors are called on thread exit.
C++ style thread-local storage, supports any C++ type.
And its syntax is portable with other C++ compilers.
The Apple LLVM Compiler, already has support for C-style thread-local storage, even when compiling C++ code.
There are two syntaxes available: One with a GCC style keyword, and another from the C11 standard.
C-style thread-local storage has lower overhead than C++ thread local, but it has restrictions.
It requires constant initializers and plain old data types.
If your code meets these restrictions, you should continue to use C-style thread-local storage for maximum performance.
Otherwise, use the C++ thread-local keyword.
Francesco Biscani
@bluescarni
Jul 29 2016 09:36
I find it mildly amusing that the native proprietary compiler/toolchains tend to be much shittier than the open source ones
Isuru Fernando
@isuruf
Jul 29 2016 09:40
Yeah, and some compilers are missing altogether like a fortran compiler
Francesco Biscani
@bluescarni
Jul 29 2016 09:40
Yep