What every programmer should know about memory, Part 1 [LWN.net]

What every programmer should know about memory, Part 1

Posted Sep 26, 2007 21:22 UTC (Wed) by k8to (guest, #15413)
Parent article: What every programmer should know about memory, Part 1

I cannot help but be a sourpuss and say: almost no programmer neeeds to know this about memory.

Some architects on software that needs good optimization should probably be acquiainted with the performance characteristics discussed, but the none of them need be aware of the circuit design. None.

to post comments

What every programmer should know about memory, Part 1

Posted Sep 27, 2007 8:09 UTC (Thu) by tyhik (guest, #14747) [Link]

"... but the none of them need be aware of the circuit design. None."

There are programmers out there, who write memory controller configuration code for boot loaders. I have done it and knowing the electrical design of memory cells really helped to answer simple questions like why the hell does DRAM need a configurable controller while the onchip SRAM is nicely ready for use right after powerup.

What every programmer should know about memory, Part 1

Posted Sep 28, 2007 15:56 UTC (Fri) by pm101 (guest, #3011) [Link] (1 responses)

Personally, I think it is useful to have a reasonable knowledge one level of abstraction down, and one level of abstraction up. There are a number of reasons for this:

You can often find optimizations that cross abstraction barriers. It is difficult to predict what you'll need to know to do this, so you really need to have a deep understanding of both layers. In some cases, you can also influence the hardware design.
You can predict how the technology may evolve.
You gain intellectual depth.

This is especially important for systems programmers -- the target of this article. If I'm designing a kernel, or a virtual machine (as in JVM, or .net runtime), or a high-performance systems library, I want to design it in such a way that it can take advantage of possible future underlying technologies.

Indeed, in many cases, I may even be able to influence underlying technologies. If I am aware of the circuit requirements of memory refresh, I can design code that explicitly leaves time for the refresh, while giving good bandwidth and latency when the memory is actually accessed. If something is a good idea, and a major OS or runtime can take advantage of it, you can bet that hardware designers somewhere will add support for it.

The major reason most CPUs only have 2-4 cores today, and didn't have multiple cores a while ago, was that software could not take advantage of them. Right now, optimum performance comes from about 64 cores at 700MHz each (the Tilera processor), but it can only be used in esoteric applications because software designers a decade ago were not aware of where the hardware is headed, and did not design applications, languages, or run-times in a parallelism-friendly way (programmer-friendly parallelism is only starting to happen today with languages like Fortress).

What every programmer should know about memory, Part 1

Posted Sep 30, 2007 20:27 UTC (Sun) by k8to (guest, #15413) [Link]

Agreed. But knowing how a dram cell is implemented is more than one level of abstraction below low-level programming, and that is more than one level of abstraction below what "every" programmer will ever deal with.