What every programmer should know about memory:<p>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.<p>It's best to acquire these skills at early age, since at older age memory stores also require more cycles.<p>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.<p>Edit: Ah, nevermind. Apparently this is a different type of memory that programmers have to deal with. Still, I hope this advice was useful.
Obligatory "Latency Numbers Every Programmer Should Know"<p><a href="http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html" rel="nofollow">http://www.eecs.berkeley.edu/~rcs/research/interactive_laten...</a>
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.<p>[1] <a href="https://www.jedec.org/news/pressreleases/jedec-announces-support-nvdimm-hybrid-memory-modules" rel="nofollow">https://www.jedec.org/news/pressreleases/jedec-announces-sup...</a><p>[2] <a href="http://www.jedec.org/sites/default/files/files/Brett_Williams_Server_Forum_2014.pdf" rel="nofollow">http://www.jedec.org/sites/default/files/files/Brett_William...</a><p>[3] <a href="https://en.wikipedia.org/wiki/NVDIMM" rel="nofollow">https://en.wikipedia.org/wiki/NVDIMM</a>
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.<p>Great Read.
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.<p>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
That one is quite the evergreen (and probably needs a '2007'):<p><a href="https://hn.algolia.com/?query=what%20every%20programmer%20should%20know%20about%20memory&sort=byPopularity&prefix&page=0&dateRange=all&type=story" rel="nofollow">https://hn.algolia.com/?query=what%20every%20programmer%20sh...</a>
On a similar note, for the difference in timings and sizes on a scale you can relate to, is this:<p><a href="https://plus.google.com/+PeterBurnsrictic/posts/LvhVwngPqSC" rel="nofollow">https://plus.google.com/+PeterBurnsrictic/posts/LvhVwngPqSC</a>
Memory product guy here.<p>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.<p>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 <i>wants</i> to understand this stuff.
there are just three things i wish programmers knew about memory... none of them are especially low-level or require depth of understanding.<p>never dynamically allocate it unless forced.<p>really. never allocate at run-time it unless you are absolutely forced by your algorithm.<p>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.