<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Le 7 nov. 2012 à 21:16, Matthieu Monrocq <<a href="mailto:matthieu.monrocq@gmail.com">matthieu.monrocq@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 12:47 AM, Seth Cantrell <span dir="ltr"><<a href="mailto:seth.cantrell@gmail.com" target="_blank">seth.cantrell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 6, 2012, at 4:04 AM, Jean-Daniel Dupas <<a href="mailto:devlists@shadowlab.org">devlists@shadowlab.org</a>> wrote:<br>
<br>
><br>
> Le 6 nov. 2012 à 01:37, James Gregurich <<a href="mailto:bayoubengal@me.com">bayoubengal@me.com</a>> a écrit :<br>
><br>
>> hi.<br>
>><br>
>> I just updated to Xcode 4.6.  I note the following:<br>
>><br>
>><br>
>> $ /Applications/Xcode46-DP1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version<br>
>> Apple clang version 4.2 (tags/Apple/clang-424.0.11) (based on LLVM 3.2svn)<br>
>> Target: x86_64-apple-darwin12.2.0<br>
>> Thread model: posix<br>
>><br>
>><br>
>> It is my understanding from the release notes, that LLVM 3.2 is support thread-local storage. I just re-ran my test using the '__thread' keyword from the last time I asked about this and I still just get one instance of the object rather than one-per-thread.<br>

<div class="im">><br>
><br>
> The __thread keyword is a C extension (it not part of the standard). Using it with C++ as is even less specified than using it with C.<br>
><br>
</div><div class="im">> Moreover, it has already be specified in the previous discussion that supporting C++ TLS required OS support. Updating Xcode does not change that.<br>
><br>
<br>
</div>gcc 4.8 now implements thread_local with a performance penalty for global thread_local variables: <a href="http://gcc.gnu.org/gcc-4.8/changes.html#cxx" target="_blank">http://gcc.gnu.org/gcc-4.8/changes.html#cxx</a><br>

<br>
I guess that function-local thread_local variables can use the same scheme for initialization as function-local static variables</blockquote><div><br><br>I would be very interested to know what this "penalty" is. I have a couple idea of what it *could* be, but no idea about what it really is.<br>
<br></div></div></blockquote><div><br></div><div>Actually it look like GCC converts thread_local access into function call with lazy initialization of thread_local variable.</div><div><br></div><div><a href="http://stackoverflow.com/questions/13106049/c11-gcc-4-8-thread-local-performance-penalty">http://stackoverflow.com/questions/13106049/c11-gcc-4-8-thread-local-performance-penalty</a> (especially the third answer that was post after your last comment on this same page)</div><div><br></div><div>There is 2 things I would like to know though; How does it handle destruction at the end of the thread, and why it can't avoid the access penalty for POD and base types. The compiler should be smart enough to detect what type require complex access, and what type support direct access.</div><br><blockquote type="cite"><div class="gmail_quote"><div>-- Matthieu <br></div></div>
</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div>-- Jean-Daniel</div><div><br></div><div><br></div></span><br class="Apple-interchange-newline">

</div>
<br></body></html>