[HN Gopher] What every programmer should know about memory (2007...
___________________________________________________________________
What every programmer should know about memory (2007) [pdf]
Author : quackulus
Score : 87 points
Date : 2023-06-21 16:18 UTC (6 hours ago)
(HTM) web link (people.freebsd.org)
(TXT) w3m dump (people.freebsd.org)
| AnimalMuppet wrote:
| (2007).
| bediger4000 wrote:
| Does the age affect how I, as a programmer, should read it?
| mdaverde wrote:
| Literally, yes.
|
| As example, the north bridge isn't as explicit today as the
| document makes it seem. A lot of functionality that used to
| be reserved for the north bridge is now being tucked away
| into the CPUs or motherboards themselves.
|
| Still, worth reading.
| burnished wrote:
| Yes, because the advice is necessarily hardware dependent.
| wmf wrote:
| This is why I think this document was too detailed and
| should have omitted low-level details. The way you optimize
| your code hasn't really changed since 2007, but the
| hardware churn since then triggers people to say "well
| akshually the northbridge..."
| kevstev wrote:
| Tbh, this paper is a bit much, unless you have a lot of time
| on your hands for it, and also the necessary understanding of
| CPU architecture to really grok it.
|
| I think there are better blog posts out there that explain
| the concepts. "Cache locality" "memory cost of context
| switching" are some terms to put in search engines. Maybe add
| "thread local storage" in there too.
|
| The big takeaway from this paper though, at least when I
| first read it, and the concept has risen to prominence in the
| years since- backed up by benchmarks- that Big O isn't really
| the end of the argument when it comes to performance.
|
| The way CPUs work is that its extremely fast to rip through
| contiguous datasets. Jumping around to random memory
| addresses is way slower. A corollary to that is that jumping
| between threads is very slow for the same reasons- loading
| and unloading random chunks of memory. There are a lot of
| details around the specifics of why though- different cache
| levels and their latencies, and what happens when there is a
| cache miss, etc..
|
| This lead HFT type programs to favor linear arrays to store
| things, and pinning threads to CPU cores, amongst other
| things, but that's the gist of it.
| cbsmith wrote:
| Yes and no. A lot of the concepts about memory management and
| how memory functions are still the same or similar. It's a
| good baseline to start with, and then look at how things have
| changed since then (they certainly have changed, but most of
| the paper still applies).
| AnimalMuppet wrote:
| Perhaps yes. Multiples cores are now much more a thing than
| they were in 2007; that at least could be a change in
| emphasis. OSes may do things differently in terms of how they
| implement memory mapping. And so on.
| PurplePants wrote:
| [flagged]
| everyone wrote:
| I dunno, I'm a game programmer and it seems a bit too much for me
| personally. I just John Carmack it, and always do the simplest
| thing _for me_ as the dev. If the benchmarks arent fit for
| purpose1 then I will look at profiler to see what lowest hanging
| fruit is to optimise. I 'm not gonna guess what is slow, I am not
| a computer, I only just look at profiler.
|
| 1This almost never happens.
| kaycey2022 wrote:
| What would be an up to date alternative to this document?
| lizardking wrote:
| Yes, every developer needs 114 pages worth of knowledge about
| memory.
| karmakaze wrote:
| I get by with latency numbers every programmer should know[0].
| Knowing a bit about how cache sharing works is helpful some
| times[1].
|
| [0]
| https://gist.github.com/hellerbarde/2843375?permalink_commen...
|
| [1] https://en.wikipedia.org/wiki/False_sharing
| redhal wrote:
| For a great read with more recent numbers, I recommend you
| checkout this post https://news.ycombinator.com/item?id=22287993
| cbsmith wrote:
| The most important stuff in this paper isn't the numbers.
| utopcell wrote:
| Still, the parent is a valuable link. Thanks for sharing.
| utopcell wrote:
| I've read this doc many years ago, and I remember it was worth
| the time. If folks are contemplating on what has changed since
| 2007 that this doc is not covering, I'd say it is CCX awareness
| for AMD CPUs.
| alberth wrote:
| FYI - this doesn't seem to be related to FreeBSD (even though
| it's hosted there).
|
| It just appears to be an external PDF that FreeBSD committer
| Lawrence Stewart saved to their fileshare, written by someone
| else.
| cbsmith wrote:
| Yeah, there's a pretty famous history on this paper (and with
| Ulrich Drepper).
| quackulus wrote:
| Please do tell
| cbsmith wrote:
| He's been the maintainer of glibc (still a developer), and
| a variety of other key bits of open source software. He's
| kind of famously abrasive/obtuse:
| https://news.ycombinator.com/item?id=2378013. The paper was
| kind of a canonical work, referenced by most everyone
| (which is no doubt why there's a copy of it on the FreeBSD
| site).
| frithsun wrote:
| What only a small subset of highly specialized programmers should
| know about memory (2007) [pdf]
| santiagobasulto wrote:
| I'm a very high level programmer, turned Data Scientist, turned
| founder (I successfully exited my prev startup). I still read
| this paper (a few years ago). I guess if you're "born" a
| programmer, all these nerdy/curious things are entertaining.
| One of my "developer" passions is multithreading and
| concurrency. Even now running my second startup, I, from time
| to time, sit to write some concurrent puzzle programs.
|
| I also like to follow Tobi Lutke. The guy is the founder/CEO of
| Shopify (with all which that might entail), and he still tweets
| amazingly interesting low level coder stuff.
___________________________________________________________________
(page generated 2023-06-21 23:01 UTC)