What            Mode      args          steps   lines

allwine.pl      Tk        ""               20     79 
boger.pl        dumb      ""               36     115
carman.pl       dumb      "100 100 20"    346*    67 
carman2.pl      dumb      "100 100 20"    296     66 
fuglerud.pl     dumb      "100 100 .2"     92     48 
gray.pl         dumb/C    "1 0.2 100 100"  65     110
haworth.pl      dumb      "100 100"       211     51  
haworth2.pl     dumb      "100 100"        74     55 
hofmann.pl      dumb      "100 100 .2"    128     51 
johnson.pl      dumb      "100 100 20"    193     49 
kennedy.pl      dumb      ""               34     361
kennedy2.pl     Tk        ""               13     362
michael.pl      dumb      "100 100 .2"    177     64 
mjd1.pl         PPM       "100 100 .2"    164     93 
mjd1d.pl        dumb      "100 100 .2"    162     94 
mjd2.pl         GIF       "1000000000"    146     137
sainio.pl       PNG       ""               46     120
sainio2.pl      dumb      ""              126     120
sanderson.pl    dumb      ".2 100 100"    154     86 
stander.pl      Tk        "-t 1"           43     188
toren.pl        curses    "100 100 20"     32     100


Notes:


If the program ran for N steps, it did 10000N cell updates in 120
seconds, for an average rate of 83.3N cells per second.  The top speed
was about 24,500 cells per second (carman2.pl).  carman.pl looks
faster, but it has a bug; see below.

The subdirectory

        http://perl.plover.com/qotw/misc/e007/CANTRUN/

contains the ones I couldn't run.  You may enjoy these, however.

The advertised -X and -Y options to stander.pl seemed not to do
anything, so I ignored them.  

mjd2.pl uses a configuration file to define the initial board setup.
The configuration I used was
        new 100 100
        random 0.2 .
        cell 50 50 *


gray.pl, kennedy.pl, kennedy2.pl, johnson.pl, michael.pl, and gray.pl
had delays built-in.  I commented these out.


carman.pl appears to be lightning fast, but that's because it has a
serious bug---the vapor particles love moving horizontally, and hate
moving vertically.  This is quite evident if you're looking for it,
and perhaps even if you're not.  I wasn't looking for it, but it
jumped out at me as I watched the output, because the resulting
crystal was so bizarre-looking.  And all the vapor disappeared from
the middle rows of the grid while the top and bottom were still very
humid.  Then I ran a small test with just a few vapor particles and
watched them move left and right.  As a result of this misbehavior,
the crystal grows way too fast, and once the vapor is all frozen, the
simulation really screams.

Here's the reason why this happens.  The code the program uses to
'rotate' the neighborhoods:

    if (int rand(2)) {
      unshift @cells, pop @cells;
    }
    else {
      push @cells, shift @cells;
    }

If the neighborhood has

        A B 
        C D

then @cells has (A B C D).  Notice that "unshift @cells, pop @cells"
produces (D A B C), which means

        D A
        B C

and similarly "push @cells, shift @cells" produces (B C D A), which is

        B C
        D A

So at each stage, *every* vapor particle moves horizontally, and half
of them move vertically.   carman2.pl corrects this, and it's *still*
the fastest by far.