Live data from Hacker News

What every programmer should know about memory (2007)

lwn.net

41–50 of 55 posts

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

#41
post #11
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.

Please don't. Blasting someone like that is rude at best, and outright mean when English is not their first language, as is the case with so many users here.

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

#42

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

I would argue that java programmers need to know this since it is even more important with a garbage collected language. Java wastes so much that the Northbridge is basically saturated with GC traffic. Sticking to a few disciplined principles can make java performance competitive.

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

#43
post #41
post #11

Earlier quoted context omitted.

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

Please don't. Blasting someone like that is rude at best, and outright mean when English is not their first language, as is the case with so many users here.

If there's anyone sensitive to the plight of a second language speaker, it's me. I can completely empathize with the struggle.

It probably wasn't the best way to phrase it and it's likely a losing battle anyway. I've found native speakers (which I believe the person I was responding to was) using this form more and more on boards such as this. Mistakes with uncountable vs plural distinctions are also increasingly common. E.g., "there's many reasons" instead of "there are many reasons".

As someone who spent years helping people with a variety of English problems including grammar, it's difficult to stop. I'll try to restrain this kind of comment to the articles themselves. There it's in the author's best interest to write in a way that doesn't cause the 30% or so of the population with stronger grammatical sensitivities to discount them.

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

#44
post #43
post #41

Earlier quoted context omitted.

Please don't. Blasting someone like that is rude at best, and outright mean when English is not their first language, as is the case with so many users here.

If there's anyone sensitive to the plight of a second language speaker, it's me. I can completely empathize with the struggle. It probably wasn't the best way to phrase it and it's likely a losing battle anyway. I've found native speakers (which I believe the person I was responding to was) using this form more and more on boards such as this. Mistakes with uncountable vs plural distinctions are also increasingly com…

I am strongly grammatically sensitive. And although I am not a native English speaker, I claim that the sentence is grammatically correct. It's just a shortened sentence form. Which is often appropriate on forums and similar.

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

#45
post #11

Earlier quoted context omitted.

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

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

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

#46
post #44
post #43

Earlier quoted context omitted.

If there's anyone sensitive to the plight of a second language speaker, it's me. I can completely empathize with the struggle. It probably wasn't the best way to phrase it and it's likely a losing battle anyway. I've found native speakers (which I believe the person I was responding to was) using this form more and more on boards such as this. Mistakes with uncountable vs plural distinctions are also increasingly com…

I am strongly grammatically sensitive. And although I am not a native English speaker, I claim that the sentence is grammatically correct. It's just a shortened sentence form. Which is often appropriate on forums and similar.

Hmm... I wouldn't have put the period between "form" and "which" in your comment either. Doing so made your last sentence a sentence fragment.

What's your native language? Your English appears to be at least very near native.

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

#47
post #43
post #41

Earlier quoted context omitted.

Please don't. Blasting someone like that is rude at best, and outright mean when English is not their first language, as is the case with so many users here.

If there's anyone sensitive to the plight of a second language speaker, it's me. I can completely empathize with the struggle. It probably wasn't the best way to phrase it and it's likely a losing battle anyway. I've found native speakers (which I believe the person I was responding to was) using this form more and more on boards such as this. Mistakes with uncountable vs plural distinctions are also increasingly com…

I'm in much the same boat as you, and I don't think it's necessary to stop; what's necessary is to err on the side of being helpful as opposed to judgmental or defensive.

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

#48
Memory 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.

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

#49
post #7
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…

I feel like you are projecting your domain specific experience on a larger more general audience than is appropriate.

you are probably right

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

#50
post #12
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…

That will basically prohibit using most of C++ STL, for example. Premature optimization is the root of...

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

Post reply on HN