Fix link in Data Locality.

munificent · munificent · commit a291c67f4d5b · 2014-09-28T19:18:15.000-07:00
diff --git a/book/data-locality.markdown b/book/data-locality.markdown
@@ -7,13 +7,13 @@
 
 ## Motivation
 
-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 
+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.
 
-Chips *have* been getting faster (though even that's plateauing now), but the 
-hardware heads failed to mention something. Sure, we can *process* data faster 
+Chips *have* been getting faster (though even that's plateauing now), but the
+hardware heads failed to mention something. Sure, we can *process* data faster
 than ever, but we can't *get* that data faster.
 
 <span name="legend"></span>
@@ -22,34 +22,34 @@ than ever, but we can't *get* that data faster.
 
 <aside name="legend">
 
-Processor and RAM speed relative to their respective speeds in 1980. As you can 
+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.
 
 Data for this is from *Computer Architecture: A Quantitative Approach*
-by John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau by way of Tony 
+by John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau by way of Tony
 Albrecht's "[Pitfalls of Object-Oriented Programming][poop]&rdquo;.
 
 [poop]: http://seven-degrees-of-freedom.blogspot.com/2009/12/pitfalls-of-object-oriented-programming.html
 
 </aside>
 
-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 
+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.
 
-With today's hardware, it can take *hundreds* of cycles to fetch a byte of data 
-from <span name="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% 
+With today's hardware, it can take *hundreds* of cycles to fetch a byte of data
+from <span name="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?
 
-Actually, they *are* 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 
+Actually, they *are* 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...
 
 <aside name="ram">
 
-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 
+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.
 
 Or, at least, you *didn't*. As we'll see, RAM isn't so random access anymore.
@@ -926,8 +926,7 @@ components?
     time you have performance-critical code that touches a lot of data, it's
     important to think about locality.
 
- *  Tony Albrecht's <a href="http://research.scee.net/files/presentations/gcapau
-    stralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"
+ *  Tony Albrecht's <a href="http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"
     class="pdf">"Pitfalls of Object-Oriented Programming"</a> is probably the
     most widely-read introduction to designing your game's data structures for
     cache-friendliness. It made a lot more people (including me!) aware of how
diff --git a/html/data-locality.html b/html/data-locality.html
@@ -35,38 +35,38 @@ <h1 class="book"><a href="/">Game Programming Patterns</a><span class="section">
 <h2><a href="#intent" name="intent">Intent</a></h2>
 <p><em>Accelerate memory access by arranging data to take advantage of CPU caching.</em></p>
 <h2><a href="#motivation" name="motivation">Motivation</a></h2>
-<p>We&#8217;ve been lied to. They keep showing us charts where CPU speed goes up and up 
-every year as if Moore&#8217;s Law isn&#8217;t just a historical observation but some kind 
-of divine right. Without lifting a finger, we software folks watch our programs 
+<p>We&#8217;ve been lied to. They keep showing us charts where CPU speed goes up and up
+every year as if Moore&#8217;s Law isn&#8217;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>
-<p>Chips <em>have</em> been getting faster (though even that&#8217;s plateauing now), but the 
-hardware heads failed to mention something. Sure, we can <em>process</em> data faster 
+<p>Chips <em>have</em> been getting faster (though even that&#8217;s plateauing now), but the
+hardware heads failed to mention something. Sure, we can <em>process</em> data faster
 than ever, but we can&#8217;t <em>get</em> that data faster.</p>
 <p><span name="legend"></span></p>
 <p><img src="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>
 <aside name="legend">
 
-<p>Processor and RAM speed relative to their respective speeds in 1980. As you can 
+<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>
 <p>Data for this is from <em>Computer Architecture: A Quantitative Approach</em>
-by John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau by way of Tony 
+by John L. Hennessy, David A. Patterson, Andrea C. Arpaci-Dusseau by way of Tony
 Albrecht&#8217;s &#8220;<a href="http://seven-degrees-of-freedom.blogspot.com/2009/12/pitfalls-of-object-oriented-programming.html">Pitfalls of Object-Oriented Programming</a>&rdquo;.</p>
 </aside>
 
-<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&#8217;t 
+<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&#8217;t
 been keeping up with increasing CPU speeds. Not even close.</p>
-<p>With today&#8217;s hardware, it can take <em>hundreds</em> of cycles to fetch a byte of data 
-from <span name="ram">RAM</span>. If most instructions need data, and it takes 
-hundreds of cycles to get it, how is it that our CPUs aren&#8217;t sitting idle 99% 
+<p>With today&#8217;s hardware, it can take <em>hundreds</em> of cycles to fetch a byte of data
+from <span name="ram">RAM</span>. If most instructions need data, and it takes
+hundreds of cycles to get it, how is it that our CPUs aren&#8217;t sitting idle 99%
 of the time waiting for data?</p>
-<p>Actually, they <em>are</em> stuck waiting on memory an astonishingly large fraction of 
-time these days, but it&#8217;s not as bad as it could be. To explain how, let&#8217;s take 
+<p>Actually, they <em>are</em> stuck waiting on memory an astonishingly large fraction of
+time these days, but it&#8217;s not as bad as it could be. To explain how, let&#8217;s take
 a trip to the Land of Overly Long Analogies&#8230;</p>
 <aside name="ram">
 
-<p>It&#8217;s called &#8220;random access memory&#8221; because, unlike disc drives, you can 
-theoretically access any piece of it as quick as any other. You don&#8217;t have 
+<p>It&#8217;s called &#8220;random access memory&#8221; because, unlike disc drives, you can
+theoretically access any piece of it as quick as any other. You don&#8217;t have
 to worry about reading things consecutively like you do a disc.</p>
 <p>Or, at least, you <em>didn&#8217;t</em>. As we&#8217;ll see, RAM isn&#8217;t so random access anymore.</p>
 </aside>
@@ -1083,8 +1083,7 @@ <h2><a href="#see-also" name="see-also">See Also</a></h2>
 important to think about locality.</p>
 </li>
 <li>
-<p>Tony Albrecht&#8217;s <a href="http://research.scee.net/files/presentations/gcapau
-    stralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"
+<p>Tony Albrecht&#8217;s <a href="http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"
     class="pdf">&#8220;Pitfalls of Object-Oriented Programming&#8221;</a> is probably the
     most widely-read introduction to designing your game&#8217;s data structures for
     cache-friendliness. It made a lot more people (including me!) aware of how
