| |||||||||||||
|
| |||||||||||||
Should disclose: x86 specificShould disclose: x86 specificPosted Oct 2, 2007 23:27 UTC (Tue) by mikov (subscriber, #33179)In reply to: Should disclose: x86 specific by ncm Parent article: Memory part 2: CPU caches
It should have been noted in the text that much of the description of multi-cache interaction is specific to x86 and similarly "sequentially-consistent" architectures. Most modern architectures are not sequentially consistent, and threaded programs must be extremely careful about one thread depending on data written by another thread becoming visible in the order in which it was written. "Modern", in this context, includes Alpha, PPC, Itanium, and (sometimes) SPARC, but not x86, AMD, or MIPS. The consequence of the requirement to maintain sequential consistency is poor performance and/or horrifyingly complex cache interaction machinery on machines with more than (about) four CPUs, so we can expect to see more non-x86 multi-core chips in use soon. I think your criticism is misdirected. The text doesn't touch on memory consistency at all - it is entirely out of its scope. Besides, you need a cache coherency protocol on any multi processor system. On the subject of memory consistency, there are different opinions. Some time ago there was a very interesting discussion in RealWorldTech where Linus Torvalds made an interesting point that it can be argued that explicit memory barriers are more expensive than what the CPU has to do in order to create the illusion of sequential memory consistency, because explicit MBs are by necessity more general and actually have stronger guarantees.
(Log in to post comments)
Should disclose: x86 specific Posted Oct 3, 2007 0:21 UTC (Wed) by ncm (subscriber, #165) [Link] "The text doesn't touch on memory consistency at all"Sorry, not true. It describes how caches of different x86 CPUs interact, but doesn't say it only describes x86, falsely suggesting that is how every other machine does it too. It leaves the reasonable reader under the impression that programmers don't need to know anything about memory consistency. That's not entirely true even on x86, but is just false on most non-x86 platforms. If Ulrich is writing for people programming only x86, the article should say so without quibbling. If not, it should call out places where it is describing x86-specific behavior.
Should disclose: x86 specific Posted Oct 3, 2007 1:14 UTC (Wed) by mikov (subscriber, #33179) [Link] I think that you may be confusing cache coherency with memory consistency. Although they are obviously related, in the context of the article the latter is not important.
To the best of my knowledge, the description in the article applies to all cache coherent systems, including the ones listed in your previous post. It has nothing to do with memory consistency, which is an issue mostly internal to the CPU.
I am very possibly wrong, of course - I am not a hardware system designer - so I am glad to discuss it. Can you describe how the cache/memory behavior in an Alpha (for example; or any other weak consistency system) differs from the article ?
Should disclose: x86 specific Posted Oct 3, 2007 1:48 UTC (Wed) by ncm (subscriber, #165) [Link] I'm sorry, I should have pointed out this quote from the article: "All processors are supposed to see the same memory content at all times.". (My emphasis.)I agree that coding with memory barriers (etc.!) is a big subject, and beyond the scope of this installment. It would have sufficed, though, to mention that (and where) it is a matter for concern, and why.
|
|
||||||||||||