Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!oxtrap.UUCP!rich From: rich@oxtrap.UUCP ("K. Richard Magill") Newsgroups: comp.emacs Subject: parallel gemacs? Message-ID: <8711171803.AA27592@oxtrap.UUCP> Date: Tue, 17-Nov-87 13:03:17 EST Article-I.D.: oxtrap.8711171803.AA27592 Posted: Tue Nov 17 13:03:17 1987 Date-Received: Sun, 22-Nov-87 08:17:28 EST References: <8711161952.AA13337@icst-cmr.arpa.ARPA> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Date: Mon, 16 Nov 87 14:52:37 EST From: Root Boy Jim 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 National Bureau of Standards Flamer's Hotline: (301) 975-5688 Why are these athletic shoe salesmen following me??