doc@dgp.toronto.edu (Blaine Price) (11/27/89)
I'm starting to build a system for visualizing and animating concurrent
programs and I would like to know what people think are the "hard" problems
in understanding parallelism. What problems occur in designing,
understanding, debugging, and maintaining parallel programs that are not as
troublesome in sequential programming? Could a real-time animation of a
running concurrent program aid in its understanding or guide optimization?
If you were working on a large program and you could automatically have
someone generate some kind of visual representation of it, what would it
look like? I have some ideas but I don't think that I have an "intuitive
handle" on how visualization can help.
Please reply by posting or e-mail, whichever you prefer.
--
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 Doctormarkv@phoenix.princeton.edu (Mark T Vandewettering) (11/30/89)
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