Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every programmer should know about memory (2007)

lwn.net

Post reply on HN
Print view View original

21–30 of 55 posts

Re: What every programmer should know about memory (2007)

#21

Post by peterwwillis »

thecatspaw wrote: post #6

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

> 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.

Re: What every programmer should know about memory (2007)

#23

Post by SilasX »

peterwwillis wrote: post #21
thecatspaw wrote: post #6

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

> 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 memo…

"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"

Re: What every programmer should know about memory (2007)

#24

Post by dboreham »

xiaoma wrote: post #11
gpvos wrote: post #9

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

> 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.

I 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.

Re: What every programmer should know about memory (2007)

#25

Post by bgilroy26 »

SilasX wrote: post #23
peterwwillis wrote: post #21

Earlier quoted context omitted.

> 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 memo…

"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"

I think there's a big difference between "read once" and "know". When some people say a fact is "known" they mean strictly that you are able to recall that fact in toto. That is probably overkill for a Web programmer.

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.

Re: What every programmer should know about memory (2007)

#27

Post by peterwwillis »

SilasX wrote: post #23
peterwwillis wrote: post #21

Earlier quoted context omitted.

> 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 memo…

"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"

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.

Re: What every programmer should know about memory (2007)

#28

Post by 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.

Re: What every programmer should know about memory (2007)

#30

Post by rikkus »

jheriko wrote: post #5

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 b…

It 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.

Post reply on HN