11–20 of 55 posts
Article is from 2007. (And as someone else writes, details have changed and the article is rather detailed.)
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.
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…
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'll remember that the next time I'm using python.
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…
Earlier quoted context omitted.
I'll remember that the next time I'm using python.
Or Java or go or ruby or Scala or php or....
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.
https://hn.algolia.com/?query=what%20every%20programmer%20sh...
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
[1] https://www.jedec.org/news/pressreleases/jedec-announces-sup...
[2] http://www.jedec.org/sites/default/files/files/Brett_William...
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…
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
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.