The number of CPUs doesn’t affect latency as long as bus bandwidth does not get saturated and (MOST IMPORTANTLY) they aren’t constantly hammering the same memory line–as is the case with spinlocks. Processors stall for long periods when pounding on heavily contended memory holding spinlocks. This is why so much work goes into breaking out work into multiple locks and why lock alternatives to spinlocks are so attractive (e.g., queued locks, read-writer locks, RCU, etc).

Noons used the term “impedance mismatch” which is fine, but in the case of Opterons, the Hypertransport is clocked at the same rate as the processor. Very elegant stuff. But, it’s NUMA and that is why I’m blogging this thread.

Just for the sake of flashback, I recall running heavily contentious Oracle workloads with bus analyzers attached back in the Sequent days. The Orion chipset that supported the Pentium Pro processor routinely stalled for 19 bus cycles (yes bus cycles at 90MHz) when invalidating heavily contended cache lines (e.g., releasing a lock). Yes, releasing a lock is expensive. At least when there are other “interested parties”.

Trivial pursuit…

Henry

No, not at all. Allow me to try and fill in for Kevin:

Memory latency is a result of the architecture and technology used to make actual memory modules. And as a consequence: the physical connectivity of the memory subsystem built around such modules.

This is fixed for a particular type or technology of memory module.

This is what Kevin means when he says: “Memory latency is nothing more that the time it takes to load or store a memory location”.

As in: the time it takes for the memory subsystem - be that a chip or a set of chips or whatever - to store or retrieve a given memory location.

Totally independent of the architecture of the “core” processor(s). Hopefully.

Processors may have one technology or architecture to access their native L1 and L2 cache memory - “native” as in residing in the same “chip” and allowing their clock rates to go at top speed - and yet use a totally different architecture and/or technology when embedded in a practical, operational system, to access that system’s main memory, at a much slower rate than the native cache.

It’s the potential mismatch - also called “impedance mismatch” in electrical engineering parlance- between the two main “classes” of memory access and their relative speeds and synchronisation that becomes interesting. And causes the “cache stalls” Kevin talks about. And how well a given technology addresses this mismatch.

Kevin, please help extricate the foot off my mouth if that’s the case.

Memory latency is nothing more that the time it takes to load or store a memory location. Letancy as a concept doesn’t differ based on core count. Different processors will staisfy their cores with varying memory latencies as per their architecture.

Thanks.