You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>We’ve been lied to. They keep showing us charts where CPU speed goes up and up every year as if Moore’s Law isn’t just a historical observation but some kind of divine right. Without lifting a finger, we software folks watch our programs magically accelerate just by virtue of new hardware.</p>
39
-
<p>Chips <em>have</em> been getting faster (though even that’s plateauing now), but the hardware heads failed to mention something. Sure, we can <em>process</em> data faster than ever, but we can’t <em>get</em> that data faster.</p>
38
+
<p>We’ve been lied to. They keep showing us charts where CPU speed goes up and up
39
+
every year as if Moore’s Law isn’t just a historical observation but some kind
40
+
of divine right. Without lifting a finger, we software folks watch our programs
41
+
magically accelerate just by virtue of new hardware.</p>
42
+
<p>Chips <em>have</em> been getting faster (though even that’s plateauing now), but the
43
+
hardware heads failed to mention something. Sure, we can <em>process</em> data faster
44
+
than ever, but we can’t <em>get</em> that data faster.</p>
40
45
<p><spanname="legend"></span></p>
41
46
<p><imgsrc="images/data-locality-chart.png" alt="A chart showing processor and RAM speed from 1980 to 2010. Processor speed increases quickly, but RAM speed lags behind." /></p>
42
47
<asidename="legend">
43
48
44
-
<p>Processor and RAM speed relative to their respective speeds in 1980. As you can see, CPUs have grown in leaps and bounds, but RAM access is lagging far behind.</p>
49
+
<p>Processor and RAM speed relative to their respective speeds in 1980. As you can
50
+
see, CPUs have grown in leaps and bounds, but RAM access is lagging far behind.</p>
45
51
<p>Data for this is from <em>Computer Architecture: A Quantitative Approach</em>
46
-
by John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau by way of Tony Albrecht’s “<ahref="http://seven-degrees-of-freedom.blogspot.com/2009/12/pitfalls-of-object-oriented-programming.html">Pitfalls of Object-Oriented Programming</a>”.</p>
52
+
by John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau by way of Tony
53
+
Albrecht’s “<ahref="http://seven-degrees-of-freedom.blogspot.com/2009/12/pitfalls-of-object-oriented-programming.html">Pitfalls of Object-Oriented Programming</a>”.</p>
47
54
</aside>
48
55
49
-
<p>For your super-fast CPU to blow through a ream of calculations, it actually has to get the data out of main memory and into registers. As you can see, RAM hasn’t been keeping up with increasing CPU speeds. Not even close.</p>
50
-
<p>With today’s hardware, it can take <em>hundreds</em> of cycles to fetch a byte of data from <spanname="ram">RAM</span>. If most instructions need data, and it takes hundreds of cycles to get it, how is it that our CPUs aren’t sitting idle 99% of the time waiting for data?</p>
51
-
<p>Actually, they <em>are</em> stuck waiting on memory an astonishingly large fraction of time these days, but it’s not as bad as it could be. To explain how, let’s take a trip to the Land of Overly Long Analogies…</p>
56
+
<p>For your super-fast CPU to blow through a ream of calculations, it actually has
57
+
to get the data out of main memory and into registers. As you can see, RAM hasn’t
58
+
been keeping up with increasing CPU speeds. Not even close.</p>
59
+
<p>With today’s hardware, it can take <em>hundreds</em> of cycles to fetch a byte of data
60
+
from <spanname="ram">RAM</span>. If most instructions need data, and it takes
61
+
hundreds of cycles to get it, how is it that our CPUs aren’t sitting idle 99%
62
+
of the time waiting for data?</p>
63
+
<p>Actually, they <em>are</em> stuck waiting on memory an astonishingly large fraction of
64
+
time these days, but it’s not as bad as it could be. To explain how, let’s take
65
+
a trip to the Land of Overly Long Analogies…</p>
52
66
<asidename="ram">
53
67
54
-
<p>It’s called “random access memory” because, unlike disc drives, you can theoretically access any piece of it as quick as any other. You don’t have to worry about reading things consecutively like you do a disc.</p>
68
+
<p>It’s called “random access memory” because, unlike disc drives, you can
69
+
theoretically access any piece of it as quick as any other. You don’t have
70
+
to worry about reading things consecutively like you do a disc.</p>
55
71
<p>Or, at least, you <em>didn’t</em>. As we’ll see, RAM isn’t so random access anymore.</p>
it was doing that before to ensure they were processed in the right order. Even
519
535
so, each component itself is still nicely encapsulated. It owns its own data and
520
536
methods. We simply changed the way it’s used.</p>
521
-
<p>This doesn’t mean we need to get rid of <code>GameEntity</code> either. We can leave it as it is with pointers to its components. They’ll just point into those
537
+
<p>This doesn’t mean we need to get rid of <code>GameEntity</code> either. We can leave it as it
538
+
is with pointers to its components. They’ll just point into those
522
539
arrays. This is still useful for other parts of the game where you want to pass
523
540
around a conceptual “game entity” and everything that goes with it. The
524
541
important part is that the performance-critical game loop sidesteps that and
they think about this pattern, they bring up a few complaints. Let’s see what we
313
313
can do to address them, if anything.</p>
314
-
<h2><ahref="#"it's-too-slow"" name=""it's-too-slow"">“It’s Too Slow”</a></h2>
314
+
<h2><ahref="#it's-too-slow" name="it's-too-slow">“It’s Too Slow”</a></h2>
315
315
<p>I hear this a lot, often from programmers who don’t actually know the details of
316
316
the pattern. They have a default assumption that anything that smells like a
317
317
“design pattern” must involve piles of classes and indirection and other
@@ -358,7 +358,7 @@ <h3><a href="#it's-too-*fast*" name="it's-too-*fast*">It’s too <em>fast?</
358
358
deadlock the game. In a highly threaded engine, you may be better off with
359
359
asynchronous communication using an <ahref="event-queue.html"
360
360
class="pattern">Event Queue</a>.</p>
361
-
<h2><ahref="#"it-does-too-much-dynamic-allocation"" name=""it-does-too-much-dynamic-allocation"">“It Does Too Much Dynamic Allocation”</a></h2>
361
+
<h2><ahref="#it-does-too-much-dynamic-allocation" name="it-does-too-much-dynamic-allocation">“It Does Too Much Dynamic Allocation”</a></h2>
362
362
<p>Whole tribes of the programmer clan — including many game developers — have
363
363
moved onto garbage collected languages, and dynamic allocation isn’t the boogie
364
364
man that it used to be. But for performance-critical software like games, memory
0 commit comments