Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Use proper lists instead of DLs with bullet points

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:34:37 +11:00
commit 7e957c0bb4
12 changed files with 83 additions and 83 deletions
Download patch file Download diff file Expand all files Collapse all files

16
17-08.html
View file

@ -47,14 +47,14 @@
<H4 ALIGN="LEFT"><A NAME="Heading11"></A><FONT COLOR="#000077">The Challenge That Ate My Life</FONT></H4>
<P>The most recent optimization challenge I laid my community of readers was to write the fastest possible Game of Life generation engine. By &ldquo;engine&rdquo; I meant that I didn&rsquo;t care about time spent in input or output, only time consumed by the call to <B>next-generation.</B> The time spent updating the cellmap was what I wanted people to concentrate on.</P>
<P>Here are the rules I laid down for the challenge:</P>
<DL>
<DD><B>&#149;</B>&nbsp;&nbsp;Readers could modify any code in Listing 17.5, except the main loop, as well as change the cell map representation any way they liked. However, the code had to produce exactly the same output as Listing 17.5 under all circumstances in order to be eligible to win.
<DD><B>&#149;</B>&nbsp;&nbsp;Engine code had to be less than 400 lines long <I>in total,</I> excluding the video-related code shown in Listing 17.2.
<DD><B>&#149;</B>&nbsp;&nbsp;Submissions had to compile/assemble with Borland C<SMALL>++</SMALL> (in either C<SMALL>++</SMALL> or C mode, as desired) and/or TASM.
<DD><B>&#149;</B>&nbsp;&nbsp;All submissions had to handle cellmaps at least 200x200 in size.
<DD><B>&#149;</B>&nbsp;&nbsp;Assembly language could of course be used to speed up any part of the program. C rather than C<SMALL>++</SMALL> was legal as well, so long as entered implementations produced the same results as Listing 17.5 and 17.2 together and were less than 400 lines long.
<DD><B>&#149;</B>&nbsp;&nbsp;All entries would be timed on the same 33 MHz 486 with a 256K external cache.
</DL>
<ul>
<li>Readers could modify any code in Listing 17.5, except the main loop, as well as change the cell map representation any way they liked. However, the code had to produce exactly the same output as Listing 17.5 under all circumstances in order to be eligible to win.</li>
<li>Engine code had to be less than 400 lines long <I>in total,</I> excluding the video-related code shown in Listing 17.2.</li>
<li>Submissions had to compile/assemble with Borland C<SMALL>++</SMALL> (in either C<SMALL>++</SMALL> or C mode, as desired) and/or TASM.</li>
<li>All submissions had to handle cellmaps at least 200x200 in size.</li>
<li>Assembly language could of course be used to speed up any part of the program. C rather than C<SMALL>++</SMALL> was legal as well, so long as entered implementations produced the same results as Listing 17.5 and 17.2 together and were less than 400 lines long.</li>
<li>All entries would be timed on the same 33 MHz 486 with a 256K external cache.</li>
</ul>
<P>That was the challenge I put to the readers. Little did I realize the challenge it would lay on <I>me:</I> Entries poured in from the four corners of the globe. Some were plain, some were brilliant, some were, well, berserk. Many didn&rsquo;t even work. But all had to be gone through, examined for adherence to the rules, read, compiled, linked, run, and judged. I learned a lot&mdash;about a lot of things, not the least of which was the process (or maybe the wisdom) of laying down challenges to readers.</P>
<P>Who won? What did I learn? To find out, read on.</P><P><BR></P>
<CENTER>