LWN: Comments on ""What every programmer should know about memory" - the PDF version"

"What every programmer should know about memory" - the PDF version

ooozzz — Sat, 17 May 2008 20:06:19 +0000

Hi. I read you great article week ago and just wrote a small narration (review?) about it (google translation).

I hope you don't suppress it.

Thank you for your great article.

Sergey.

link to each part?

corbet — Tue, 27 Nov 2007 17:03:57 +0000

You'll find all the links at the end of the first installment. Yes, I know, that's perhaps not the most obvious place...

link to each part?

shapr — Tue, 27 Nov 2007 16:51:27 +0000

Could the links to all the parts be in one place?
It's not easy to click from part one to part two and further.

Definition of "cache coherency"

ncm — Sat, 24 Nov 2007 10:37:18 +0000

A fundamental error found on page 16 remains.

The erroneous text is, "In symmetric multi-processor (SMP) systems the caches of the CPUs cannot work independently from each other. All processors are supposed to see the same memory content at all times. The maintenance of this uniform view of memory is called 'cache coherency'." (Emphasis added.)

There are two errors here. First, it is not true that on all SMP systems, all processors are supposed to see the same memory content at all times. It is normal, e.g. on SMP PPC and Itanium systems, for different CPUs to see different values at the same address for some time after a write operation by one CPU, unless "barrier instructions" have been run after the write operation on both the writing and reading processors. The second error is related: the text above is not a correct definition of "cache coherency" as used by modern computer architects. Cache coherency requires that all processors eventually see writes by others (e.g., after the barrier instructions), not that they see the effect of all writes immediately.

The x86 architecture definition provides guarantees to the programmer about when writes by one processor are visible to others without barrier instructions, but these guarantees make the cache architecture much more complex, and less able to scale efficiently to more than a few processors. This complexity also makes it just that much less likely that the cache system will actually have been implemented correctly in every case. Unfortunately, buggy hardware remains in service long after the bug is known, making these "guarantees", and code that depends on them, less reliable.

(If these turn out to be the only serious errors in the document, it would remain a remarkable achievement.)

"What every programmer should know about memory" - the PDF version

ikm — Sat, 24 Nov 2007 03:59:16 +0000

I guess the redistribution of the URL is still allowed, though :)

"What every programmer should know about memory" - the PDF version

paravoid — Sat, 24 Nov 2007 03:18:31 +0000

It's a great read!
Not that I'm not grateful, but sadly, it's rather non-free.
Not even redistribution is allowed.
I'd really love to be able to distribute this to fellow programmers...