What every programmer should know about memory (2007)
lwn.net
lwn.net
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.
http://www.eecs.berkeley.edu/~rcs/research/interactive_laten...
[1] https://www.jedec.org/news/pressreleases/jedec-announces-sup...
[2] http://www.jedec.org/sites/default/files/files/Brett_William...
Great Read.
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
We have GB and GB of memory in our computers today, but all of the "I don't have to worry about memory constraints" have snowballed. The application we run today are nowhere near as efficient as they could be otherwise.
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]).
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.
After you read something once you don't strictly know it. However if you run into a related problem down the road, you have a good chance that you can remember enough of what you read once to put a Google query together and find the original article.
After thinking about it a little more, what they probably mean is that while most programmers will forget most of what they read here (because they don't use it day-to-day) it is reliable information that will help shape their intuition about how memory works. That is probably what they mean about every programmer and this article.
Every programmer ought to read and test their intuition about how memory works against the content in this article. If they are surprised by something they read, they have the chance to adjust their intuition so that it is closer to the truth.
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.
There's knowing how fuel injectors work, and there's knowing how copper crystal in the wire admits an energy band for free electrons.
https://hn.algolia.com/?query=what%20every%20programmer%20sh...
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.
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.
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.
but yes... i do have frustration from "highly skilled native programmers" who seem to think that memory is a boundless resource and then complain that something like 32GB is a constrained memory environment when it is the exact opposite.
STL is not too bad either. you can make it work with budgets too... implementing a custom allocator is a pain, but there are lots of ways to not write code that imagines that memory is an infinite resource...
Though you can still build up crud depending upon the system.
what happens is that the stack is once dynamically allocated up-front when the thread is created and an index into that blob of memory is incremented and decremented as appropriate (stack pointer).
you can call that allocation, and it would be accurate but its not what i meant at all. it also avoids growing your memory consumption and doesn't impact memory budgets no matter how much stack you try and use (you will overflow it instead... and will need to allocate a bigger budget upfront for the stack with a compiler flag)
I'll give one: Performance takes a hit with dynamic allocation. Deallocation also has to occur and if you use GC you may experience pauses as this happens. Your GC may vary. The performance inpact of dynamic allocation may of course be completely acceptable when traded against productivity gains.
using memory as an endless resource without thinking seems to be standard practice rather than something that is considered "sloppy".
there is also the practice involved. run-time allocation is a bit of a golden sledgehammer and a double edged sword... sure you can write code more quickly, but you are also being enabled to write worse code (i.e. leaks). i don't think we should take the power away, but respect it more...