EDP 2008 Parallel Computing Bingo

<h1>EDP 2008 Parallel Computing Bingo</h1>

<table BORDER CELLSPACING=2 CELLPADDING = 1>
<tr><td> 17 Transistors are free </td><td> 9 Mutilate the algorithm to match the architecture </td><td> 24 We don't have any other choice </td><td> 13 Universities don't teach parallel programming </td><td> 23 Everyone will encode video 24 hours a day </td></tr><tr><td> 20 Our ideas are so revolutionary, we can't even simulate them </td><td> 12 AI </td><td> 3 Scale up the problem size </td><td> 19 This new programming language will fix everything </td><td> 7 Compare with parallel implementation rather than best serial </td></tr><tr><td> 15 Programmers are lazy </td><td> 5 Compare to scalar unoptimized Cray </td><td> FREE </td><td> 1 Inner kernel, not the system </td><td> 2 Compare assembly to Fortran or C </td></tr><tr><td> 14 We've never had parallel systems before </td><td> 6 Compare with old, obsolete system </td><td> 0 Quote 32-bit as 64 </td><td> 16 The previous generation didn't know about Moore's Law </td><td> 11 Show Pretty Pictures </td></tr><tr><td> 8 Quote processor utilization </td><td> 10 Compare dedicated system to multi-user </td><td> 4 Project linearly </td><td> 21 We'll demonstrate that it works next year </td><td> 22 All computing tasks are just like ray tracing </td></tr></table>

With the end of clock rate scaling, there's been a mad dash towards
multi-core architectures.  While not widely known, there has in fact
been prior attempts to use parallel computing.  Things have not necessarily
gone well.

To make the impending disaster more entertaining, we can play Parallel
Computing Bingo while listening to technical talks and keynotes; this
is a game similar to WWDC Bingo.

On the bingo card are twelve classic observations from a 1991 paper by
David Blyler, highlighting ways in which the performance of parallel
computers were completely misrepresented.  Many of these are alive and
well, and appear on a regular basis.  The second set of twelve are the
result of a highly scientific study performed at the 2008 IEEE DATC Electronic
Design Processes workshop.  Together, with a center "free" cell, they make
a bingo card that can be played at conferences around the world.  Individual
bingo cards can be downloaded from the EDP web site.


For more information about the original 12, please refer to:
<a href="http://portal.acm.org/citation.cfm?id=147877.147941&coll=Portal&dl=GUIDE&CFID=63548383&CFTOKEN=46243598">Misleading Performance in Supercomputing Field</a> by D. H. Bailey.

In summary, they are as follows.
<ul>
<li>0: Quote 32-bit as 64.  A tremendous performance advantage can be gained by
putting the run times of your 32-bit machine up against a 64-bit competitor.  In
current times, it's even better to put a fixed precision GPU up against
an IEEE-standard arithmetic unit in a modern processor.

<li>1: Inner kernel, not the system.  Amdahl's law calculates the speedup of the
entire system; there's always a serial bottleneck somewhere, resulting in
asymtotic performance improvement.  By reporting only the portion of the run
time that can be improved linearly, results look much more impressive.

<li>2: Compare assembly to Fortran or C.  This is more difficult in todays
environment, where both Fortran and C have good compilers, and all the
people who can program in assembly are in retirement homes.  As an alternative,
we might consider instead comparing C to Java running in a web browser.

<li>3: Scale up the problem size. A classic way to improve parallel computing
results is to make the problem much bigger.  For a simulation, if you can't get
good scaling with results that are accurate to .01%, try getting accuracy
to .0001%.  Still not enough?  Keep going.  It might take a run of weeks, and
accuracy beyond any measurable 

<li>4: Project linearly.  It's possible to get fantastic scaling if you simply
project such performance, without the trouble of actually building and
testing the system.

<li>5: Compare to scalar unoptimized Cray.  Probably less common now, so
consider this one any comparison involving a system clearly not designed
to operate in a given way.

<li>6: Compare with old, obsolete system.  Similar to 5.

<li>7: Compare with parallel implementation.  Many times, there can be
an efficient serial algorithm, while the parallel implementation has
a great deal of overhead.  The parallel algorithm might scale, but if
there's a computational complexity mismatch, the best serial algorithm
will win (and we don't want that!).

<li>8: Quote processor utilization.  It's easy to keep processors busy, as
long as they don't need to do useful work.

<li>9: Multilate the algorithm to match the architecture.  Again, this is
a form of tuning, to unfairly disadvantage other approaches.

<li>10:Compare dedicated system to multi-user.  If there are extra processes
burdening the other system, it's easier to show speedup.

<li>11:Show Pretty Pictures.  Whenever someone starts asking tough questions,
just distract them!

<li>12: AI.  Thinking Machines claimed that they would build a parallel machine "that would be proud of them."  The AI claims were so extreme that no one dared
ask them to perform some sort of demonstration.  

<li>13: Universities don't teach parallel programming.  Of course, NSF and
DARPA have funded parallel computing researchers for decades.  One might wonder
what sorts of classes these folks teach.

<li>14: We've never had parallel systems before.  Apparently, the history of
parallel computing is a well kept secret.

<li>15: Programmers are lazy.

<li>16: The previous generation didn't know about Moore's Law; this explains
why so many parallel computing companies started, and then failed.

<li>17: Transistors are free.  In some sense true, if new fab lines and the research
and development of new technology nodes are also free.  Commonly used to justify
having hundreds of cores sit idle.

<li>18: This new architecture will fix everything.

<li>19: This new programming language will fix everything.

<li>20: Our ideas are so revolutionary, we can't even simulate them.  This is
the "smoke and mirrors" approach to obtaining funding, and is quite effective.

<li>21: We'll demonstrate that it works next year.  Previously used in DNA
computing, currently popular with both quantum and CNT; now coming to our
research community.

<li>22: All computing tasks are just like ray tracing.  Ray tracing is
embarassingly parallel, so it's desirable to claim that other tasks will
enjoy similar scalable.

<li>23: Everyone will encode video 24 hours a day.

<li>24: We don't have any other choice.
<ul>
17 Transistors are free	9 Mutilate the algorithm to match the architecture	24 We don't have any other choice	13 Universities don't teach parallel programming	23 Everyone will encode video 24 hours a day
20 Our ideas are so revolutionary, we can't even simulate them	12 AI	3 Scale up the problem size	19 This new programming language will fix everything	7 Compare with parallel implementation rather than best serial
15 Programmers are lazy	5 Compare to scalar unoptimized Cray	FREE	1 Inner kernel, not the system	2 Compare assembly to Fortran or C
14 We've never had parallel systems before	6 Compare with old, obsolete system	0 Quote 32-bit as 64	16 The previous generation didn't know about Moore's Law	11 Show Pretty Pictures
8 Quote processor utilization	10 Compare dedicated system to multi-user	4 Project linearly	21 We'll demonstrate that it works next year	22 All computing tasks are just like ray tracing