3 ms·

I just recently took an advanced computer architecture course, and I was stunned by how little I knew about how computers ~actually~ work. Most people think "m

by habosa 13y ago

I just recently took an advanced computer architecture course, and I was stunned by how little I knew about how computers ~actually~ work. Most people think "memory is fast, disk is slow" but the reality is "high-level caches are fast, other caches are slow, memory is really slow, and stay the hell away from disk". You're always taught to think in terms of memory but the good news is that very intelligent cache designers have made accessing memory directly a relatively infrequent event, and that's one of the only reasons our processors get to do any work at all.

SixSigma 13y ago
If nanoseconds were seconds is a must read https://plus.google.com/app/basic/stream/z13uuj5a0qjhfv43r23rdrubguulz1qxw04 https://plus.google.com/app/basic/stream/z13uuj5a0qjhfv43r23... Also Grace Hopper's nanosecond illustration http://highscalability.com/blog/2012/3/1/grace-hopper-to-programmers-mind-your-nanoseconds.html http://highscalability.com/blog/2012/3/1/grace-hopper-to-pro...
tinco 13y ago
Ulrich Drepper wrote a terrible paper titled "What every programmer should know about memory"[1]. It covers basically everything involving memory. It's much too long and really only is relevant for programmers who want (need) to make optimal use of memory. I wouldn't recommend it, but every time someone realises how slow some memory things are compared to other memory things, I guess it's obligatory to link it. So here, don't read it ;) 1] http://www.akkadia.org/drepper/cpumemory.pdf http://www.akkadia.org/drepper/cpumemory.pdf
- munificent 13y ago
  If you want a friendlier introduction to the topic with some basic patterns to optimize for it, I wrote a chapter in my book on game programming about caching: http://gameprogrammingpatterns.com/data-locality.html http://gameprogrammingpatterns.com/data-locality.html While the book is ostensibly about games, there's relatively little game-specific about it.
coldtea 13y ago
>Most people think "memory is fast, disk is slow" but the reality is "high-level caches are fast, other caches are slow, memory is really slow, and stay the hell away from disk". Which is also far from the truth, which is any part of this pipeline can be fast or slow, depending on what you're using it for.

by habosa 13y ago

SixSigma 13y ago

If nanoseconds were seconds is a must read https://plus.google.com/app/basic/stream/z13uuj5a0qjhfv43r23rdrubguulz1qxw04 https://plus.google.com/app/basic/stream/z13uuj5a0qjhfv43r23... Also Grace Hopper's nanosecond illustration http://highscalability.com/blog/2012/3/1/grace-hopper-to-programmers-mind-your-nanoseconds.html http://highscalability.com/blog/2012/3/1/grace-hopper-to-pro...

tinco 13y ago

Ulrich Drepper wrote a terrible paper titled "What every programmer should know about memory"[1]. It covers basically everything involving memory. It's much too long and really only is relevant for programmers who want (need) to make optimal use of memory. I wouldn't recommend it, but every time someone realises how slow some memory things are compared to other memory things, I guess it's obligatory to link it. So here, don't read it ;) 1] http://www.akkadia.org/drepper/cpumemory.pdf http://www.akkadia.org/drepper/cpumemory.pdf

munificent 13y ago
If you want a friendlier introduction to the topic with some basic patterns to optimize for it, I wrote a chapter in my book on game programming about caching: http://gameprogrammingpatterns.com/data-locality.html http://gameprogrammingpatterns.com/data-locality.html While the book is ostensibly about games, there's relatively little game-specific about it.

coldtea 13y ago

>Most people think "memory is fast, disk is slow" but the reality is "high-level caches are fast, other caches are slow, memory is really slow, and stay the hell away from disk". Which is also far from the truth, which is any part of this pipeline can be fast or slow, depending on what you're using it for.