The GnuVision Blog

The title of this paper is an homage to David Goldberg’s classic paper “What Every Computer Scientist Should Know About Floating-Point Arithmetic” [goldberg]. Goldberg’s paper is still not widely known, although it should be a prerequisite for anybody daring to touch a keyboard for serious programming.

Read What every programmer should know about memory - part 1
and part 2

Read the comments too, they are interesting.

You may wonder whether you need to understand stuff like how a DRAM cell is implemented using a capacitor and a transistor or how a SRAM cell is implemented using six transistors. Here is what one reader says:

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.

Another reader suggests:

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.

It’s not too difficult get a feel of the impact of memory architecture - here is a simple experiment.