Photo CD Demo 1/Demo.bin/cellsim/v2_5/doc/cm.doc

Text File | 1990-02-26 | 13.8 KB | 294 lines

            Documentation for Cellsim v2.5
             Connection Machine interface
              February, 1990


           ****************************************
  Version 2.5 of Cellsim can communicate with a daemon process on a
Connection Machine front-end (CMFE), transferring data (such as lookup
tables and images) and instructions to the CM, and reading data (such
as images and state-counts) back.  This essentially allows you to
run your CA rules on a Connection Machine (CM), while still using the
Sun as a user-interface.

  You can do this by running Cellsim on one of the CM front-ends (assuming
it's a Sun), or you can do this remotely through the network.  I've
successfully run Cellsim attached to a CM 2000 miles away (it was pretty
slow though)!

  Both lookup-table (LT) and computed-function rules can be used.
To use LT rules, you don't need to know any CM programming, as you
generate the LT's locally, and then transfer them to the CM.  To use
computed-function (256-state) rules on the CM, however, you will have
to program the rules in C/Paris, a semi-low-level language on the CM
which you call from C.


           ****************************************
           STARTING THE DAEMON ON THE CMFE

  To use the CM, you need to run a program on the CMFE which will wait for
the Sun side of Cellsim to call it up.  This program is "cm_cell".

  Go to the directory that has the cm_cell program (either "cm_cell.sun4"
or "cm_cell.vax", but referred to simply as "cm_cell" here) on the CMFE.
Attach to the CM using the "cmattach" command, to grab whatever Sequencer(s)
and interface you want, however many processors you want, etc.  You should
now be in an attached shell.  Run the "cm_cell" program.  You can give it
a couple of arguments to set either the debug-level (to make it be *very*
verbose about what the Sun is telling it to do), or to change the port-number
from the default of 12700.  The form of those optional arguments is:
  cm_cell -d # -p #
where the first # is the debug-level (0 is the default if you don't use
the -d argument), and the second # is the port to use.  Right now, only
two debug-levels are supported: 0, very quiet, and 1, very verbose.
So some possible command-lines are:
  cm_cell -d 1
  cm_cell -p 12705
  cm_cell -d 1 -p 12714

  Note also that you can just invoke cm_cell when attaching, by doing
the following, for example:
  cmattach -w -S 2 cm_cell -d 1

  I recommend just doing a cmattach to get an attached shell, and then
running cm_cell from the shell.  The reason for that is, sometimes cm_cell
or Cellsim crashes, and if you are not in an attached shell, you'll lose
the CM when you crash, and someone else might grab it from you.  It can be
very frustrating.  (Hopefully, cm_cell will not crash too often any more...)


           ****************************************
          CONNECTING TO CM_CELL FROM CELLSIM

  Ok, now you've got cm_cell running, what next?  You should run Cellsim
on a Sun somewhere.  You can use command-line arguments to Cellsim to
tell it the name of the CMFE you are running cm_cell on, or if the person
who compiled Cellsim was nice or was you, Cellsim will automatically know
which CMFE you're most likely to want.  You can also specify the port
number to use.  Finally, you can also set the hostname and/or port number
from within Cellsim, using the "Defaults" menu.

  So once you've done all that, you should click the left mouse-button
on the "CM" button in the control panel, or select "Connect to CM" from
the "CM" menu.  However, in order to do this, you have to be in a neighorhood
and image-size that is allowed on the CM.  These are as follows:

  Valid image sizes for use with CM: 128, 256, 512  (64 is too small)
  Valid neighorhoods: m2, v2, v4, v8, M2, M4, M8, l2r1, l4r1, l8r1, l16r1,
              l2r2, l4r2, l8r2, l2r3, l4r3, any 256-state nhood

This means you *cannot* use the following neighborhoods with the CM, that
you could use on the Sun:
  m4, v16, M16, l16r2
This is because the lookup table would be too large.  Apparently, some
CMs (that I use, at least) will be getting memory upgrades from
8 kbytes/processor up to 32 kbytes/processor, so future releases of Cellsim
might allow you to use larger tables.  However, there's not much need, if
you know C/Paris, since computed-function rules go almost as fast as
lookup-tables on the CM!

  Anyways, when you click on the "CM" button to connect to the CMFE, the
control panel in Cellsim will probably flash some messages too quickly
for you to see (they are just handshaking messages between Cellsim and
cm_cell, which you can read when they happen individually; a bunch of
things have to be done when first connecting though).  Eventually, you
should see the message "Connected to CM".

ERRORS
  If you *don't* get that message, you might see one of 2 things:
"Error trying to connect to CM" means that there wasn't anybody waiting
on the host/port Cellsim tried to call.  Either you got the hostname
or port wrong, or you didn't run cm_cell, or the host-table on your
machine is wrong, or the network is messed up, or something of that nature.
Check everything very carefully and try again.
  If you see "Not connected!", that means Cellsim did connect, but something
happened that caused the connection to break, such as cm_cell crashed.
I'd suggest changing some parameters in Cellsim, such as the image-size
or neighborhood, and trying again, although that shouldn't be the cause
of the problem.  But I find that different CMs have very different sets
of problems, and I've only tested Cellsim on 3 CMs so far.

  If you just can't get Cellsim to connect to the CM successfully, send
a message to me, Dave Hiebeler ([e-mail]), and we'll
debug your situation.  Different CMs behave very differently, in my
experience, so it may take some fine-tuning to get it working on your CM.
(Feel free to do some hacking yourself, and contact me if you don't get
it running).


           ****************************************
           USING THE CM, NOW THAT YOU'RE CONNECTED

  So you're connected to the CM.  It's a good feeling, right?  Well, let's
go through a simple example.  Say you want to run Life.  You can load the
lookup table for Life locally, using the "Rules" menu.   Then, select
"Send LT" from the "CM" menu, to send the lookup table to the CM.  Next,
you can draw an image locally, and send it to the CM ("Send image" under
the "CM" menu).  Or, you could use "CM quick random" or "CM general random"
to generate an image very quickly out on the CM, since sending an image
is pretty slow.
  Now everything's out there and ready to run.  Make sure you've enabled
whichever display devices you want to use, in the "CM" popup window under
the "defaults" menu.  You can either use "Run", or "Skip", or "Skip/Bounded",
or any of those, to run.
  Note that if you're only using the Sun display (no FrameBuffer), then
if you hit "Run", you won't see anything until you hit the left mouse-button
to stop running.  It would severely strain the network to send back every
image to the Sun.

  If the "life.m2" LT was on the CMFE filesystem, and you had the CM Image-dir
set up appropriately, you could use the "Load rule from CMFE" item under
the "CM" menu, to just load the LT directly into the CM, rather than loading
it on the Sun and then sending it.

RUNNING A 256-STATE PARIS RULE
  For our next trick, let's run a 256-state C/Paris rule.  Select
"Load rule from CMFE" under the "CM" menu, and enter "heat.m256.sun4.o"
or "heat.m256.vax.o", depending on which type of CMFE cm_cell is running on.
You'll probably also want to load in the "rainbow256.cmap" colormap, and
send that to the CM (use the "send cmap" item under the "CM" menu in the
control panel).  Then, select "quick random" under the "CM" menu, and you're
ready to run!  If you have a FrameBuffer, this rule runs very smoothly; if
you're only using a Sun display, you'll just have to look at an image once
in a great while -- but things will still run fast on the CM!


           ****************************************
              DISCONNECTING FROM THE CM
       ("I'll let someone else use the machine for a change.")

  To disconnect things, select "disconnect" from the "CM" menu.  That will
close the socket connection between Cellsim and cm_cell.  However, cm_cell
won't exit; it will sit and wait for another Cellsim (or the same one)
to call it up again.  To kill it, hit control-c (or whatever your interrupt
character is, if you've changed it) in the window where you are running it.
The interrupt signal tells cm_cell to stop waiting, close the socket, and
exit.  Then you can detach from the CM by exiting your attached shell.  (You
will automatically detach if you ran cm_cell as an argument to cmattach).


           ****************************************
       SPEED OF COMPUTED-FUNCTION VS LOOKUP-TABLE RULES

  Running a computed-fcn rule on the CM isn't as bad as on the Sun.  The
reason for that is, on the Sun, the update-function gets called for every
cell, but on the CM, the update-function gets called *once*, to update *all*
the cells.

  For simple update-functions, such as heat.m256, there are about a dozen
Paris calls.  For lookup-tables, there are 2 Paris calls, but they are very
slow ones (aref32-shared and a normal aref).  So you don't lose much speed
at all.  If your update-function has millions of Paris calls, then you'll
suffer a loss in speed, of course, but things will still be pretty fast
compared to the Sun!


           ****************************************
           YOU CAN DO A LOT MORE THAN 8 BIT RULES!

  Perhaps one of the more pleasant realizations I had when writing the
CM code, was that when using a computed-function rule, you can use a lot
more than 8 bits per cell.  In fact, less than a dozen bytes per virtual
processor are used (when not using lookup-tables), so with a VP ratio of
16, you've got around 500 bytes/VP left.  (The VP ratio is 16 when running
with a 512x512 image on 16384 processors).

  Because of this, it is possible to allocate extra fields on the CM from
within your rule, and use those fields in your update-function.  Right now,
you have to do this extra work yourself; Cellsim will maintain (and display)
an 8-bit field for you, and look up the neighbors from that field.  If
you want neighbors from your private fields, you have to look them up.
You also have to put stuff into the supplied 8-bit field for display,
if you want to see anything or send things to the Sun.

  Despite those restrictions, Cellsim still has the potential to be used as
a somewhat general interface for 2-D geometries on the CM.  I've even written
a floating-point rule which ran under Cellsim/cm_cell!

  See the "CM.Fcn" file for more information about constructing C/Paris
rules, and how to make rules that use more than 8 bits.


           ****************************************
               COMMON MISTAKES

  One of the most common mistakes I make is to load an LT on the Sun, and
then try to run on the CM without ever sending the LT to the CM.  I plan to
eventually have Cellsim warn the user when that happens, but I haven't
implemented it yet.  So if you try to run a rule and *very* strange things
happen, you should check to make sure you sent everything to the CM --
LT, image, cmap, etc.

           ****************************************
                   WARNINGS
  The CM code is fairly new, and fairly fragile at this point.  You will
probably find lots of ways to make it crash or just screw up.  I can think
of at least one thing that would probably cause problems: trying to use
fewer cells than physical processors.  Although one of the CMs I use is
a 64k-processor CM, I generally seize at most 1/4 of the machine, or
16k processors.  I suspect that if you run on 32k processors and try to
use a 128x128 array (16384 cells), the CM program will crash.  I'd test
this myself, but of course it's the night before I want to release this
program...

  Occasionally, things just go wrong, causing something to crash.  Usually,
if cm_cell crashes, Cellsim will notice and will tell you it's disconnected
from the CM.  Once in a while, it won't notice, and things will hang.
Sometimes you can use "Disconnect" in the "CM" menu, to disconnect after
cm_cell has crashed (it doesn't make sense to disconnect from a program
that's no longer running, but what it does is tell Cellsim to close the
socket).  When things get really messed up, you should kill both cm_cell
and Cellsim, to make sure the socket is closed and everything can be
restarted.  Sometimes sockets won't die, and cm_cell will complain that
the address is already in use.  Usually, the socket will time out after
a minute or so, but if it won't, you can use a different port number instead.

  If all this makes you nervous, don't worry about it until you've tried
it out.  Some CMs seem to behave very well, and others give more trouble.


/*
 *
 * Cellsim copyright 1989, 1990 by Chris Langton and Dave Hiebeler
 * ([e-mail], [e-mail])
 *
 * This package may be freely distributed, as long as you don't:
 * - remove this notice
 * - try to make money by doing so
 * - prevent others from copying it freely
 * - distribute modified versions without clearly documenting your changes
 *   and notifying us
 *
 * Please contact either of the authors listed above if you have questions
 * or feel an exception to any of the above restrictions is in order.
 *
 * If you make changes to the code, or have suggestions for changes,
 * let us know!  If we use your suggestion, you will receive full credit
 * of course.
 */

/*****
 * Cellsim history:
 *
 * Cellsim was originally written on Apollo workstations by Chris Langton.
 *
 * Sun versions:
 *
 * - version 1.0
 *   by C. Ferenbaugh and C. Langton
 *   released 09/02/88
 *
 * - version 1.5
 *   by Dave Hiebeler and C. Langton  May - June 1989
 *   released 07/03/89
 *
 * - version 2.0
 *   by Dave Hiebeler and C. Langton  July - August 1989
 *   never officially released (unofficially released 09/08/89)
 *
 * - version 2.5
 *   by Dave Hiebeler and C. Langton  September '89 - February 1990
 *   released 02/26/90
 *****/