rich@oxtrap.UUCP (K. Richard Magill) (11/13/87)
Can anyone verify the feasability of lack thereof of a parallel version of gnu-emacs? What I want to know is, is there a good reason that eval, map*, etc. cannot be done in parallel? Like, does the existing lisp code presume sequential execution? I could just write it and try it, but if someone can tell me simply that gnu-emacs-lisp does indeed make such assumptions then I won't bother. On the other hand, if there is a guarentee that I am not aware of... If eval, map*, etc, cannot, then maybe I will just background garbage collection. After all, most of the time N-1 of the processors on my sequent are idle. Its also pretty silly that my sun 3/50 runs gnu faster than my sequent. :-). rich.
jr@LF-SERVER-2.BBN.COM (John Robinson) (11/14/87)
>> Can anyone verify the feasability of lack thereof of a parallel >> version of gnu-emacs? What I want to know is, is there a good reason >> that eval, map*, etc. cannot be done in parallel? Like, does the >> existing lisp code presume sequential execution? Well, this depends on the e-lisp "language definition" (which of course doesn;t really exist). And, for the C code, there is most probably a necessity that things generally happen sequentially. Lisps of various flavors do provide some functions that make no guarantees about their evaluation order. (let ...) versus (let* ...) for example. Whether programmers have necessarily followed the rules in their use of these constructs is another matter. Parallel garbage collection is an even nastier matter. Master's thesis material at least (but don't let this daunt you, please!). BBN Advanced Computers is working on a parallel Lisp which is based on MIT scheme; scheme's tighter semantics make it better for parallel implementation for many of the same reasons it is more tractable for compilation. Maybe you could start with the scheme that FSF distributes. There are a lot of different ways you can think about for parallelizing Lisp. I believe ACI is using the lazy evaluation model - the result of an expr need not be known until it is needed by someone else. This lets you parallelize in, for example, picking up function arguments. The trouble, of course, is in side effects. Again, this is why scheme's semantics are so much of a help, in this case because they force you to write code that will execute properly in a parallel environment. /jr jr@bbn.com or jr@bbn.uucp
rbj@ICST-CMR.ARPA (Root Boy Jim) (11/16/87)
Can anyone verify the feasability of lack thereof of a parallel version of gnu-emacs? What I want to know is, is there a good reason that eval, map*, etc. cannot be done in parallel? Like, does the existing lisp code presume sequential execution? Maybe yes, maybe no. It probably doesn't matter. The relevant question is what percent of your program can be done in parallel. If only ten percent of your program can be done in parallel, and the rest must be done serially, then even an infinite number of processors will only give you a 10% speedup. Sequent's parallel processing stuff works by creating or using multiple processes. In this case, the synchronization would probably overwhelm the speedup. Don't bother. rich. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Why are these athletic shoe salesmen following me??
rich@oxtrap.UUCP ("K. Richard Magill") (11/17/87)
Date: Mon, 16 Nov 87 14:52:37 EST
From: Root Boy Jim <rbj@icst-cmr.arpa>
Can anyone verify the feasability of lack thereof of a parallel
version of gnu-emacs? What I want to know is, is there a good reason
that eval, map*, etc. cannot be done in parallel? Like, does the
existing lisp code presume sequential execution?
Maybe yes, maybe no. It probably doesn't matter. The relevant question is
what percent of your program can be done in parallel. If only ten percent
of your program can be done in parallel, and the rest must be done serially,
then even an infinite number of processors will only give you a 10% speedup.
Sequent's parallel processing stuff works by creating or using multiple
processes. In this case, the synchronization would probably overwhelm
the speedup. Don't bother.
You might be surprised at how tightly atomic lock memory and shared
physical memory syncronize. We aren't talking signals and sleeps
here. It's that 10% of the time when I run a moderate chuck of lisp
that I'd like to see sped up by an infinite factor. 90% of the time
emacs is faster than I am, but 10%...
rich.
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
Why are these athletic shoe salesmen following me??rich@oxtrap.UUCP (11/23/87)
WHATS GOING ON HERE!!! I SENT THIS AS MAIL!!! In article <8711171803.AA27592@oxtrap.UUCP> rich@oxtrap.UUCP ("K. Richard Magill") writes: > > Date: Mon, 16 Nov 87 14:52:37 EST > From: Root Boy Jim <rbj@icst-cmr.arpa> > > Can anyone verify the feasability of lack thereof of a parallel > version of gnu-emacs? What I want to know is, is there a good reason > that eval, map*, etc. cannot be done in parallel? Like, does the > existing lisp code presume sequential execution? > > Maybe yes, maybe no. It probably doesn't matter. The relevant question is > what percent of your program can be done in parallel. If only ten percent > of your program can be done in parallel, and the rest must be done serially, > then even an infinite number of processors will only give you a 10% speedup. > > Sequent's parallel processing stuff works by creating or using multiple > processes. In this case, the synchronization would probably overwhelm > the speedup. Don't bother. > >You might be surprised at how tightly atomic lock memory and shared >physical memory syncronize. We aren't talking signals and sleeps >here. It's that 10% of the time when I run a moderate chuck of lisp >that I'd like to see sped up by an infinite factor. 90% of the time >emacs is faster than I am, but 10%... > > rich. > > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> > National Bureau of Standards > Flamer's Hotline: (301) 975-5688 > Why are these athletic shoe salesmen following me?? filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler