7 ms·
What every programmer should know about memory (2007)
- jheriko 11y agothere 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.
- progmal1 11y agoI feel like you are projecting your domain specific experience on a larger more general audience than is appropriate.
- jheriko 11y agoyou are probably right
- rootlocus 11y agoI'll remember that the next time I'm using python.
- azinman2 11y agoOr Java or go or ruby or Scala or php or....
- vvanders 11y agoStill 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 11y agoFew applications need this... mostly in the financial space. The GC is quite good at quick temp objects these days.
- jheriko 11y agoi'm not sure using a dynamic late scripting language is an excuse for pretending memory is infinite. :) 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.
- yongjik 11y agoThat will basically prohibit using most of C++ STL, for example. Premature optimization is the root of...
- jheriko 11y agoi'm not a fan of that religious statement. its assuming it is premature. 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...
- aidenn0 11y agoYou do know that function stack frames are dynamically allocated (just not from the heap in most C and C++ implementations).
- Namrog84 11y agoMaybe he is coming from the fact that lots of things still leak memory this day and age. And you tend to not leak memory when you avoid dynamic allocation? Though you can still build up crud depending upon the system.
- jheriko 11y agoin a sense yes, but its not a realistic way to use the term. 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)
- rikkus 11y agoIt would help to give reasons why rather than simply commandments. 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.
- jheriko 11y agotrue. i wasn't just thinking about performance but also budgetting. 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...
- fmstephe 11y agoI 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 11y agoWiki 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
- ilurk 11y agoObligatory "Latency Numbers Every Programmer Should Know" http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html http://www.eecs.berkeley.edu/~rcs/research/interactive_laten...
- petewailes 11y agoOn 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
- thecatspaw 11y agothis 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
- SilasX 11y agoExactly. As the saying goes, whenever I hear "what every programmer needs to know about ...", I unsafety my Browning.
- JustSomeNobody 11y agoWrong. Every programmer should know this stuff. You may not be directly manipulating memory in python, but you should know enough about memory (and other scarce resources) to know when you need to optimize your application. How are you going to know when you need to use __slots__ in python? Should java programmers just blindly throw -Xms<size> when they think they need it? How should they justify that? 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.
- peterwwillis 11y ago> 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.
- 11y ago
- gpvos 11y agoArticle is from 2007. (And as someone else writes, details have changed and the article is rather detailed.)
- xiaoma 11y ago>Article is from 2007. Do you mean the article? Do you mean an article? There's a missing article in this comment. Edit: downvoting doesn't make it any less true. However unrepentant about bad grammar you may be, the point stands and I don't regret the comment.
- dboreham 11y agoI think it is very clear that he means the cited article. The post title should include the year (2007) since technology has changed somewhat in the 8 years since.
- gugagore 11y agoI disagree with your judgement about the grammatically of the utterance. And if you've ever written comments about anything, for example, someone's writing or pictures, you'll probably say things like "me in Peru" or "needs revising" or "word is inappropriate"
- xiaoma 11y agoI would never say, "word is inappropriate". I would say, "This word is inappropriate". It's clearer and there's almost no cost to using a well-formed sentence. Similarly, I find comments where the single word "this" is used as an entire sentence detract from a forum based site. I can talk to u in allthememes! and sms abbreviations, but I chose to save that register for chat and look for something a bit more correct on forums. I readily admit that HN has been slowly trending away from that for nearly its entire existence.
- gugagore 11y agoI was on the subway and saw "DON'T LEAN ON DOOR" and remembered this thread. Your comment about "this" and internet shorthand and memes is not related to your grammaticality judgement, unless you are admitting to conflating "clarity" with "propriety".
- pvg 11y agoThat one is quite the evergreen (and probably needs a '2007'): https://hn.algolia.com/?query=what%20every%20programmer%20should%20know%20about%20memory&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=what%20every%20programmer%20sh...
- wyldfire 11y agoWhat 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-support-nvdimm-hybrid-memory-modules https://www.jedec.org/news/pressreleases/jedec-announces-sup... [2] http://www.jedec.org/sites/default/files/files/Brett_Williams_Server_Forum_2014.pdf http://www.jedec.org/sites/default/files/files/Brett_William... [3] https://en.wikipedia.org/wiki/NVDIMM https://en.wikipedia.org/wiki/NVDIMM
- vvanders 11y agoUnless 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.
- eco 11y agoThis is on a different tier entirely from NVDIMMs but I've been wondering lately about whether all of the cache locality efforts are going to go to waste or even be counter productive as hardware advances. Effective cache locality requires jumping through a lot of hoops.
- draw_down 11y agoDefinitely start off with a huge preamble about the olden days and document structure and how to report problems. Sheesh
- asgard1024 11y agoWhat 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.
- mwnz 11y agoAgain?
- Dowwie 11y agowait.. I have to know ALL of this?! is there a TL;DR?
- dang 11y agohttps://hn.algolia.com/?query=What%20every%20programmer%20should%20know%20about%20memory&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0 https://hn.algolia.com/?query=What%20every%20programmer%20sh...
- mud_dauber 11y agoMemory 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.