31–40 of 55 posts
Earlier quoted context omitted.
Or Java or go or ruby or Scala or php or....
Still 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.
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. [1] https://www.jedec.org/news/press…
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…
You do know that function stack frames are dynamically allocated (just not from the heap in most C and C++ implementations).
Though you can still build up crud depending upon the system.
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
Earlier quoted context omitted.
"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 da…
There's knowing how fuel injectors work, and there's knowing how copper crystal in the wire admits an energy band for free electrons.
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
Earlier quoted context omitted.
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 da…
You know, I have a really hard time imagining a situation where your boss storms up to your desk and says "Why aren't the goddamn wheels moving? We're losing ad revenue every minute!!" and you reply "Aww goddamn, I forgot to account for DRAM refresh cycle." There's knowing how fuel injectors work, and there's knowing how copper crystal in the wire admits an energy band for free electrons.
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.