Messages in this thread | | | From | Samuel Tardieu <> | Subject | Re: Is gcc thread-unsafe? | Date | Thu, 25 Oct 2007 11:40:22 +0200 |
| |
>>>>> "Nick" == Nick Piggin <nickpiggin@yahoo.com.au> writes:
Nick> Hi David, [BTW. can you retain cc lists, please?]
Nick> On Thursday 25 October 2007 14:29, David Schwartz wrote: >> > Well that's exactly right. For threaded programs (and maybe even >> > real-world non-threaded ones in general), you don't want to be > >> even _reading_ global variables if you don't need to. Cache misses >> > and cacheline bouncing could easily cause performance to >> completely > tank in some cases while only gaining a cycle or two >> in > microbenchmarks for doing these funny x86 predication things. >> >> For some CPUs, replacing an conditional branch with a conditional >> move is a *huge* win because it cannot be mispredicted.
Nick> A *conditional* store should no be a problem.
Nick> However the funny trick of doing this conditional add Nick> (implemented with unconditional store), is what is going to Nick> cause breakage.
Nick> On the CPUs where predicated instructions are a big win, I'd Nick> expect they should also implement a conditional store for use Nick> here. However they might be slower than an unconditional store Nick> (eg. x86's cmov), and in those cases, gcc might just do the Nick> non-conditional store.
>> In general, compilers should optimize for unshared data since >> that's much more common in typical code. Even for shared data, the >> usual case is that you are going to access the data few times, so >> pulling the cache line to the CPU is essentially free since it will >> happen eventually.
Nick> This is not just a question of data that you were going to use Nick> anyway. gcc generates memory accesses to locations that would Nick> never be accessed Even stores. It is basically impossible to say Nick> that this is a real performance win. Even on single threaded Nick> code: consider that cache misses take the vast majority of time Nick> in many loads, which gives a little hint that maybe it's a bad Nick> idea to do this ;)
>> Heuristics may show that the vast majority of such constructs write >> anyway. So the optimization may also be valid based on such >> heuristics.
Nick> I'd never say the optimisation would always be useless. But it's Nick> a nasty thing to have on by default, and apparently even with no Nick> good way to supress it even if we want to.
>> A better question is whether it's legal for a compiler that claims >> to support POSIX threads. I'm going to post on >> comp.programming.threads, where the threading experts hang out.
Nick> Either way, I think we really need a way to turn it off for Nick> Linux.
-- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |