
What every programmer should know about memory (2007) - jimsojim
http://lwn.net/Articles/250967/
======
dang
[https://hn.algolia.com/?query=What%20every%20programmer%20sh...](https://hn.algolia.com/?query=What%20every%20programmer%20should%20know%20about%20memory&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

------
asgard1024
What every programmer should know about memory:

Even though it may not seem so at first, memory is very lossy, especially in
old age. So, write comments, write documentation, make notes. Diagrams help
too.

It's best to acquire these skills at early age, since at older age memory
stores also require more cycles.

There are also ways to boost memory. One option is that emotionally charged
events are very well remembered. Thus, don't be afraid to experiment; the
bigger mistake you make, the better you will remember it.

Edit: Ah, nevermind. Apparently this is a different type of memory that
programmers have to deal with. Still, I hope this advice was useful.

------
ilurk
Obligatory "Latency Numbers Every Programmer Should Know"

[http://www.eecs.berkeley.edu/~rcs/research/interactive_laten...](http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html)

------
wyldfire
What every programmer should know: large capacity and blazing fast NAND is
poised to change everything you used to know. JEDEC is working on
standardizing large capacity NVDIMMs [1][2][3], and that will probably mean at
the very least a new tier in this hierarchy. And perhaps changes to swap,
filesystems, databases, and boot/initialization will come to capitalize on
this new tier.

[1] [https://www.jedec.org/news/pressreleases/jedec-announces-
sup...](https://www.jedec.org/news/pressreleases/jedec-announces-support-
nvdimm-hybrid-memory-modules)

[2]
[http://www.jedec.org/sites/default/files/files/Brett_William...](http://www.jedec.org/sites/default/files/files/Brett_Williams_Server_Forum_2014.pdf)

[3]
[https://en.wikipedia.org/wiki/NVDIMM](https://en.wikipedia.org/wiki/NVDIMM)

~~~
vvanders
Unless they get CAS latency down(the little I know about flash points to
probably not) I don't know if it's going to change that much.

------
fmstephe
I would love to read an updated version of this. The fundamentals won't have
changed much. But the details are changing and Urlich went into a lot of
detail in this doc.

Great Read.

~~~
rasz_pl
Wiki could work for updating this writeup efficiently, good example is the way
linux booting was described using github.

[https://github.com/0xAX/linux-insides](https://github.com/0xAX/linux-insides)

------
thecatspaw
this is way to low level for every programmer to know. While there probably is
some use for this, the average java/python/ruby/node.js programmer will never
need this information.

When working with embedded systems this information is more usefull, but very
few programmers actually do work in that industry compared to others, e.g. web

~~~
peterwwillis
> the average java/python/ruby/node.js programmer will never need this
> information

That's what every kid in school ever says about a subject they don't care
about. They're usually proven wrong.

Just in the first few pages you'll find this gem:

    
    
      This leakage is why a DRAM cell must be constantly refreshed. For
      most DRAM chips these days this refresh must happen every 64ms. During
      the refresh cycle no access to the memory is possible. For some workloads
      this overhead might stall up to 50% of the memory accesses (see [highperfdram]).
    

You don't think a Java, Python, Ruby, or Node programmer might need to know
this at some juncture?

Having a deep understanding of how things work helps you visualize everything
going on and see potential problems before they happen. This kind of deep
thinking is helpful in all kinds of activities.

~~~
SilasX
"Would benefit, eventually, at some point when butting up against resource
limitations if they're advanced and do this for a while and no one's around to
point this out of them on code review" != "everyone needs to know"

~~~
peterwwillis
I think I get what you're saying here. You don't "need" to know this to write
code. Which is true - heck, you don't "need" to know how a tcp/ip connection
works, or how disk storage works. But one day you might.

When you put fuel in your car and you turn the ignition and step on the gas,
the wheels move. So all you need to know is where the fuel goes and how to
turn the ignition and where the gas pedal is. But one day, I guarantee you,
the wheels will stop moving.

When your boss storms up to your desk and says "Why aren't the god damn wheels
moving?! We're losing ad revenue every minute!!", I hope Code Review Guy is
around to tell you how fuel injectors work.

~~~
yongjik
You know, I have a really hard time imagining a situation where your boss
storms up to your desk and says "Why aren't the goddamn wheels moving? We're
losing ad revenue every minute!!" and you reply "Aww goddamn, I forgot to
account for DRAM refresh cycle."

There's knowing how fuel injectors work, and there's knowing how copper
crystal in the wire admits an energy band for free electrons.

~~~
peterwwillis
The point isn't to know the answer to every problem. The point is to be
educated enough to even have a _guess_ as to where to start _looking_ for the
problem, and then start trying to figure out the answer.

------
pvg
That one is quite the evergreen (and probably needs a '2007'):

[https://hn.algolia.com/?query=what%20every%20programmer%20sh...](https://hn.algolia.com/?query=what%20every%20programmer%20should%20know%20about%20memory&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

------
gpvos
Article is from 2007. (And as someone else writes, details have changed and
the article is rather detailed.)

~~~
TheBakaAniki
I wish that was the case. I wouldn't have to worry about DRAM latencies
anymore

------
petewailes
On a similar note, for the difference in timings and sizes on a scale you can
relate to, is this:

[https://plus.google.com/+PeterBurnsrictic/posts/LvhVwngPqSC](https://plus.google.com/+PeterBurnsrictic/posts/LvhVwngPqSC)

------
mud_dauber
Memory product guy here.

Great content & relatively current. FWIW, the subject gets even more
interesting if you consider how switches & routers manage the flow of packets.
The memory hierarchy gets even more esoteric.

Regarding the "this is too low level for programmers" comment: only if you
don't need to understand how latency, bandwidth & power works at a fundamental
level. Every programmer I know _wants_ to understand this stuff.

------
jheriko
there are just three things i wish programmers knew about memory... none of
them are especially low-level or require depth of understanding.

never dynamically allocate it unless forced.

really. never allocate at run-time it unless you are absolutely forced by your
algorithm.

if you absolutely really must allocate memory on the fly, have a budget so you
can do one big up-front allocation and carefully reuse it. even better, don't
allocate it to start with.

~~~
rootlocus
I'll remember that the next time I'm using python.

~~~
azinman2
Or Java or go or ruby or Scala or php or....

~~~
vvanders
Still very much relevant in Java if you don't want your GC to churn like mad.

Heck even some of the cache aware algorithms can be taken advantage of with
some smart use of ByteBuffers to get a 10-50x improvement in performance.

~~~
azinman2
Few applications need this... mostly in the financial space. The GC is quite
good at quick temp objects these days.

------
draw_down
Definitely start off with a huge preamble about the olden days and document
structure and how to report problems. Sheesh

------
Dowwie
wait.. I have to know ALL of this?! is there a TL;DR?

------
mwnz
Again?

