On Thu, Jul 26, 2012 at 1:28 AM, Stefan Ring <stefan...@gmail.com> wrote:
> > In addition, most systems only support loading memory in cache lines. > > IIRC, today most cache lines are 16KB. So when you read a single byte, > > the 16KB around that memory location is loaded as well. > > The cache line size on x86 is 32 bytes on 32 bit systems, not 16KB. On > 64 bit systems, it's 64 bytes. Eh, you're right....I knew I was mixing something up there. I dug up CPU-Z on my windows machine and you're right, 32KB L1 cache, 64byte line size. > > So there's a odd side-effect here. Notice how it locks a whole cache > > line (16KB)? This means that if you allocated 4K atoms from the same > > cache line, swapping one would cause the others to lock during the > > CAS. > > Sort of, but this false sharing and subsequent performance degradation > happens whether or not you use CAS to access the items in a cache > line. How so? If I have 4 cores all reading from the same cache line, with no writers, there won't be a cache degradation issue there will there? Ah, I just looked up "false sharing". You're mentioning that the issue is with multiple writers to the same cache line, but different elements in the cache. Yes, I agree, that's a performance problem. I guess in the original context we were discussing LOCK vs CAS. It seems to me that hardware deadlocks could be a big issue if two cores tried to aquire exclusive access to elements that existed in the same cache line. As a side note, I'm super psyched about the new Hardware Transactional Memory being implemented by Intel and AMD. It'll probably be a long time before we get it in Java, but it's pretty cool none-the-less. http://www.realworldtech.com/haswell-tm/ The Intel approach has a bad limitation in that it tracks all memory modified in a transaction (instead of allowing the programmer to mark certain reads as non-critical), so the AMD approach may end up being the better solution here. Timothy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
