Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!usc!apple!excelan!unix!hplabs!hp-sdd!ncr-sd!ncrcae!hubcap!markv
From: markv@phoenix.princeton.edu (Mark T Vandewettering)
Newsgroups: comp.parallel
Subject: Re: What's "hard" about parallel programming?
Keywords: visualization, animation, concurrency
Message-ID: <7234@hubcap.clemson.edu>
Date: 29 Nov 89 16:37:15 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 29
Approved: parallel@hubcap.clemson.edu

In article <7201@hubcap.clemson.edu> doc@dgp.toronto.edu (Blaine Price) writes:
> [ Asks what is hard about visualizing the execution of concurrent 
    programs]


In my (obviously radical and biased) opinion, most of the problems that
arise from trying to comprehend concurrent execution comes from time 
dependant behavior, ie.  synchronization problems.  For instance, 
having to rendezvous at various points in the execution path before
continuing.

In a previous life when I was examining parallelism in functional
programming languages, I considered doing a graphic oriented execution
monitor.  The particular language I was examining worked via combinator
reduction, where the program is represented by a graph that is slowly
(or hopefully quickly) transformed into a normal form by graph
rewriting.  We can get parallelism because many sites in the graph are
possible rewrite positions at any point in execution.  I imagined
a graphics interface with subtress changing colors as they become 
executable, and again when they begin execution on a physical processor.
When the results are finally computed, the subtree is replaced by
its reduced data value.

I unfortunately never implemented such a system.

>Blaine Price  (416) 978-6619, fax: 4765         doc@dgp.utoronto.{ca,bitnet}
>Dynamic Graphics Project, Dept. of Computer Sci.         doc@dgp.toronto.edu
>Univ. of Toronto, Canada M5S 1A4               ...!uunet!dgp.toronto.edu!doc
>"Who do I work FOR? I don't work FOR anyone! I'm just having fun."-The Doctor


Brought to you by Super Global Mega Corp .com