

What every programmer should know about memory [2007] - pagejim
http://lwn.net/Articles/250967

======
bradleyland
Every programmer does not need to know this.

Coming from a programming background and moving more in to the management side
of things, I've come to learn that while it's a lot of fun to know the
minutia, it is not necessary to do your job. It can even be a waste of time.

The Six Sigma (I can feel you rolling your eyes) folks have a tool they call
KPI (key performance indicators). KPI is like an abstraction for management.
Think of it like a benchmarking or profiling utility for your organization.
The purpose of the KPI is to abstract away the underlying complexity of the
tasks being performed and answer the question: "Is our performance adequate?"
This should help managers to avoid micro-managing their staff.

A generalist programmer does not need to know the internal differences between
SRAM and DRAM because there is no change or improvement they can effect by
knowing these details; not even on the optimization side of things. They only
need to know how the two affect application peformance. To dig deeper is to
commit to micro-managing the computer. Even worse, there's nothing you can
change about the way SRAM or DRAM operates.

I understand completely if you _enjoy_ knowing this kind of thing. I do to. I
just don't accept that every programmer needs to know this.

------
kilburn
I somehow asumed that the article was about the human's memory works, and tips
on how to maximize your (programming) efficiency by better exploiting your
working memory.

I guess I'll have to wait for that. Bummer! hehe

