3 ms·

For those interested about RAM timings, effects of cache, and other low level memory topics explained exceptionally well, check out "What Every Programmer Shoul

• barrkel 17y ago
  That book is detailed, but that's also the problem with it. The relevant signal is all but drowned in the noise of 114 pages of details of CAS/RAS, circuit diagrams for SRAM and DRAM cells, bus protocols for hardware transactional memory, descriptions of Linux APIs for configuring NUMA support, etc.; frankly, things that need not be known unless dealing with those issues specifically. In the article of this post, on the other hand, a handful of key characteristics of the cache hierarchy are graphically displayed using pretty minimal code snippets and attractive graphs. I believe programmers would generally be better served by the intuitions gained from the blog post than daunted by the exhaustive detail and verbose presentation of Ulrich's book. IOW, keep in mind simple things like: measure; be aware of the cheapness of adjacent accesses, of the possibility of false sharing with certain strides, of the cost of following pointers, of the pitfalls of concurrent access to adjacent memory locations, and even serial access to the same memory location (dependencies wrt ILP). Concentrate on building a mental model for providing intuitions of cache behaviour at the appropriate level of abstraction, but always be prepared to measure to verify intuitions, as the hardware changes all the time, and different architectures can give rise to surprisingly different results.
  • ajross 17y ago
    Then perhaps you might be serve better by the linked article, which is kinda the "dumbed down" version of the Drepper whitepaper. But I don't see why detail is bad. The Drepper paper is pretty much the only place, short of JEDEC specs and manufacturer datasheets, where you can get an exposition about how modern DRAM works. (FWIW: his similar whitepapers on ELF shared libraries and glibc TLS are equally great, and also pretty much the canonical review documents on those subjects.)
    • palish 17y ago
      But I don't see why detail is bad. Too much detail is bad because it hides the relevant knowledge. That is, there are certain paragraphs / certain images that the programmer will remember. Those are the important components. Brevity is good.
    • Groxx 17y ago
      Too much detail is bad in the same way that an intro biology course flooding you with chemical equations for bodily functions (when chem is not a prerequisite), literally hundreds of new terms, many of which are fairly isolated, and a hundred medium-rare diseases is bad. What do you end up remembering? "Body-stuff is hard." And 90% of what you read falls out of your head in a year, along with 90% of the useful stuff. If it's trimmed down, you may lose 50%, and 50% of the useful stuff, which covers all of the generally useful stuff in the massive 10-kilo textbook that covers more than a biochem grad student remembers. Fewer relatively-unrelated (or seen-as-useless) facts also make it easier to form logical connections with the remaining facts, which help you remember and apply what you've learned.