For an accessible talk about the real-world implications of this, I enjoy watching Mike Acton's CppCon talk "Data-Oriented Design and C++": https://www.youtube.com/watch?v=rX0ItVEVjHc
What Every Programmer Should Know About Memory (2007) [pdf]
81–90 of 101 posts
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#82Earlier quoted context omitted.
memcpy != memmove , $#$@#@ https://sourceware.org/bugzilla/show_bug.cgi?id=12518
https://sourceware.org/bugzilla/show_bug.cgi?id=3266 https://sourceware.org/bugzilla/show_bug.cgi?id=12701 https://sourceware.org/bugzilla/show_bug.cgi?id=386 https://sourceware.org/bugzilla/show_bug.cgi?id=10134
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#83Earlier quoted context omitted.
You don’t need to know any of that to know that streaming access is more efficient than random access. You just need to know that caches cache localized blocks. Actually, you don’t even need to know that. You could even just be told that streaming access is faster than random access.
This is how cargo cult programming begins.
It's called working on the relevant level of abstraction.
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#84Earlier quoted context omitted.
Proved their point? Their point didn't make much sense. What actual engineers NEED to know about floating point numbers could be put on a single A4 page. It doesn't have to be 50 pages, where many of those pages are full of equations that 99% of engineers don't understand. My point is, because you seem to have trouble grasping this. Most real-world programmers, working at startups or bigger companies, making their WP…
I know that beginner Ruby programmers are constantly surprised by floating point arithmetic results due to not understanding how they work. I see it all the time.
> What actual engineers NEED to know about floating point numbers could be put on a single A4 page.
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#85Earlier quoted context omitted.
Every programmers should know something about memory, because software are becoming bloat [1] [2] because of a new generation of programmers who doesn't optimize their code. So, of course, you had a wonderful career, but it doesn't prove that you write efficient code [1] http://www.rntz.net/post/against-software-development.html [2] http://tonsky.me/blog/disenchantment/
Is it better for my company if the software is delayed to market by 6 months because we were writing the most optimal code possible in low-level languages gaining us 5% more speed on our application? Most programmers are working for a business whose goal is to make money. Usually that involves adding more features or producing the product faster (as in development time). As far as optimal or efficient goes, all the c…
> all the company cares about is: "Is it fast enough so that people still buy/use the product?
Studies have shown that is not the case.
Amazon found that every 100ms of latency cost them 1% in sales. Google found that 400 milliseconds means a nearly 0.5% decrease in search sessions.
So yes, a 5% speedup in an application could be an enormous win for a company.
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#86Earlier quoted context omitted.
> I'm not saying it's not interesting, but it's not going to change how I write my for-loops and if statements or make calls to BigTable, etc. You might be surprised at how much changing your for loops can be when accessing matrix data. for(int i=0; i Test that out, and you'll see a major performance improvement. ----------- If someone is writing high performance code, the #1 goal is to be able to read your profiler'…
If I saw that code at my company, I'd ask why someone building a rest api for web-services had to iterate through a 10000*10000 2D array while calling a method of every single cell. This isn't a use case I've seen in my 10 year career thus far. Also, you have to understand that saving 1 or 2 milliseconds isn't important when compared to getting software built faster. For the typical use case, optimizing a for-loop li…
> If I saw that code at my company, I'd ask why someone building a rest api for web-services had to iterate through a 10000*10000 2D array while calling a method of every single cell
Why not? I work with the scripting languages only and regularly hit this scenario so I won't say this is completely useless.
When you analyze a few hundred 50GB files for specific patterns, you have to go line by line in those cases shaving off milliseconds, optimizing how data should be accessed and optimized becomes valuable.
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#87Earlier quoted context omitted.
No, he's right. It's more than simply semantics. A better title would be "an extremely overwhelming of programmers don't need to know THIS much about memory"
Or perhaps some more positive phrasings: - If you know this much about memory, you'll know more than 99% of programmers. - What 99% of programmers don't know about memory.
The second one reads like a Buzzfeed article...
> What 99% of programmers don't know about memory... number 17 will shock you!
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#88Is this title and content supposed to be ironic? I quickly perused the article and I think this link should be renamed "What 99.9% of programmers don't need to know about memory." I've managed to go from Associate to Principal without knowing 99% of what's covered in this document, and I'm struggling to understand why the average Java, C#, Python, Rust, programmer would need to know about transistor configurations or…
Maybe it's because I'm a physicist and not a software engineer, but it's nice to know how things work all the way down even if in the end, a phenomenological model is all you need to do your work.
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#89Earlier quoted context omitted.
I know that beginner Ruby programmers are constantly surprised by floating point arithmetic results due to not understanding how they work. I see it all the time.
> What actual engineers NEED to know about floating point numbers could be put on a single A4 page.
I don’t think you could explain the issues sufficiently on one page. I think you'd be left with more questions and confusion than answers.
Re: What Every Programmer Should Know About Memory (2007) [pdf]
#90Is this title and content supposed to be ironic? I quickly perused the article and I think this link should be renamed "What 99.9% of programmers don't need to know about memory." I've managed to go from Associate to Principal without knowing 99% of what's covered in this document, and I'm struggling to understand why the average Java, C#, Python, Rust, programmer would need to know about transistor configurations or…
I'm sure some programmers don't need to know this. For example an Erlang or Haskell programmer can't do anything about memory layout anyway, so this knowledge would be of no immediate practical use.
> For example an Erlang or Haskell programmer can't do anything about memory layout anyway
No, but we can make algorithms that will do things in other ways than standard. Knowing memory layout and behaviour enables programmer to invent better ways to do things. Of course those algorithms are very application specific, but at least it increases solution space. Erlangers mantra here is "profile this" so that you know which one is actually better.