Memory Half 2: CPU Caches
It should have been famous in the textual content that a lot of the description of multi-cache interaction is particular to x86 and similarly "sequentially-consistent" architectures. Most modern architectures are not sequentially consistent, and threaded programs have to be extremely careful about one thread relying on knowledge written by another thread becoming visible within the order by which it was written. Alpha, PPC, Itanium, and (typically) SPARC, but not x86, Memory Wave AMD, or MIPS. The consequence of the requirement to keep up sequential consistency is poor performance and/or horrifyingly complicated cache interaction equipment on machines with greater than (about) 4 CPUs, so we will anticipate to see extra non-x86 multi-core chips in use quickly. I think your criticism is misdirected. The text would not touch on memory consistency in any respect - it is totally out of its scope. Moreover, you want a cache coherency protocol on any multi processor system. On the subject of memory consistency, there are completely different opinions.
Some time ago there was a very fascinating dialogue in RealWorldTech where Linus Torvalds made an fascinating point that it may be argued that express memory barriers are dearer than what the CPU has to do as a way to create the illusion of sequential memory consistency, because express MBs are by necessity extra common and MemoryWave even have stronger guarantees. Sorry, not true. It describes how caches of various x86 CPUs interact, Memory Wave however does not say it only describes x86, falsely suggesting that is how every different machine does it too. It leaves the reasonable reader below the impression that programmers don't need to know anything about memory consistency. That's not completely true even on x86, but is just false on most non-x86 platforms. If Ulrich is writing for individuals programming solely x86, the article ought to say so with out quibbling. If not, it ought to name out locations the place it's describing x86-particular habits. To the better of my information, the description in the article applies to all cache coherent techniques, together with those listed in your earlier submit.
It has nothing to do with memory consistency, which is an issue principally inside to the CPU. I'm very presumably fallacious, after all - I'm not a hardware system designer - so I'm glad to discuss it. Are you able to describe how the cache/memory conduct in an Alpha (for instance; or every other weak consistency system) differs from the article ? I agree that coding with memory boundaries (etc.!) is a giant topic, and past the scope of this installment. It could have sufficed, although, to say that (and the place) it is a matter for concern, and why. 86 and x86-sixty four really aren't sequentially-consistent, as a result of this might lead to an enormous performance hit. They implement "processor consistency" which means masses can cross shops but no different reordering is allowed (aside from some special instructions). Or to put it one other way, masses have an acquire barrier and MemoryWave stores have a launch barrier.
Implementations can situation masses to the bus out of order, but will invalidate early hundreds if necessary to attain the identical have an effect on as if all loads had been finished so as. Express memory barrier instructions may be essential or useful even on x86 and x86-64. However ideally programmers will use portable locking or lockless abstractions as an alternative. The idea of disabling hyperthreading (SMT) within the BIOS as a manner to reduce cache misses and presumably increase efficiency is attention-grabbing (and pertinent to me as I run a system with such a CPU and motherboard). In any case, my CPU seems to utilize this feature about 10% of the time, and even then it's often (99.99% of the time) with two distinct, non-threaded purposes. It does seem logical that, if the hyperthreaded CPU shows as two CPUs to the OS (I get two penguins at boot time plus cat /proc/cpuinfo shows two processors), but each digital CPU is sharing the identical 512K of L2 cache, then possibly my Laptop is sucking rocks in performance because of the cache miss price alone.
reference.com