grunwald@uiucdcsm.cs.uiuc.edu (12/04/87)
I did a stint with 'big blue' one summer as an intern in their entry systems division (read: PC-land). I'd been a mainframe mavine before then, and I was agast at what they were doing. They seriously expected someone to dish out may $$ for what amounted to a file transfer program & telphony interface. Not only that, but to use the thing at all, you had to devote an entire PC to their thing. How much simpler (? ok, maybe not, but certainly more useful) it is to have a task monitor the telephone interface & let you do real work with the rest of your PC. Single user systems? Maybe. Single task systems, no not today, thanks? dirk ``i don't own a blue tie anymore'' grunwald grunwald@m.cs.uiuc.edu
franka@mmintl.UUCP (Frank Adams) (12/08/87)
In article <3300014@uiucdcsm> grunwald@uiucdcsm.cs.uiuc.edu writes: >Not only that, but to use the thing at all, you had to devote an entire PC >to their thing. That "entire PC" can be had for under $1000 today. In a few years, you may be able to get it for under $100. Now how concerned are you about devoting an entire PC to the task? Just to clarify, it is my opinion that multi-tasking *is* the wave of the [near] future for micro-computers. All I'm saying is that it isn't a sure thing. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
preece@ccvaxa.UUCP (12/17/87)
fay@encore.UUCP: > Every fork() (or thread_create() in Mach) in every program can get > scheduled on a different cpu (that includes every shell per user, > daemon, background task, ... Also, don't forget all those kernel > processes (or tasks, threads) running on different cpus (pagers, signal > handlers, ...). How difficult is it when the O.S. does it > transparently? ---------- Oh, goody, then I can just forget about all my cache history, whether my process has to go through any extra latency to get to its memory, inter-processor signalling delays, and all those little things that get tacked on when everything isn't all in one big processor? There is a reasonably strong literature showing that, in general, each additional processor buys you less additional throughput than the one before (ELXSI to the contrary notwithstanding). There are some nasty overheads and bottlenecks that add up; in most implementations they add up more than linearly. > Since this is not true, the only thing to overcome is common prejudice. > Price/performance advantage (for small multiprocessor minis and up) is > huge. [I must confess, someone inside encore told me once that the good thing about the machine was its flat response to additional load -- it started out like a soggy 750 and stayed just the same until the load killed it completely, which is not bad for the processors involved.] > By the way, I don't fault people for not understanding about multis > (e.g., from past exposure or school). It takes some time for common > misconceptions to catch up to current reality. Nobody outside of sales and marketing should try to claim that current reality is anything but "Nobody understands multiprocessing yet." It certainly is not the case that the kind of simple task migration mechanisms you describe can buy anything like effective transparent use of multiprocessing beyond a very small number of shared memory processors. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@Gould.com
aglew@ccvaxa.UUCP (12/17/87)
(I'm not quite so pessimistic as my manager, who has a previous post, about parallel processing. But that's another story... By the way, I'm collecting information about superlinear speedups, as reported for ELXSI et al. I'd appreciate it if anybody can send me reports of superlinear speedups, both single process and workload.) Just read the latest Communications of the ACM, with the example of the Michael Jackson style of programming in "Literate Programming". Now, when I first heard of Jackson, I thought "what is this crap" and moved on. But now I'm not so sure. Especially since the Jackson methodology seems to promote a "pipelined" sense of dataflow. On present machines he has an implementation technique that "inverts" a pipeline into normal code; but, a pipeline might be able to make better use of multiprocessors than many other parallel programming techniques. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.
johnson@uiucdcsp.cs.uiuc.edu (12/19/87)
/* Written 1:04 pm Dec 16, 1987 by fouts@orville.nas.nasa.gov in uiucdcsp:comp.arch */ As an example of a class of algorithms which is difficult to vectorize or parallelize, let me pull out the ancient prime finder algorithm: ... Although there are different algorithms for finding primes, I use this one to illustrate a class of problems which comes up frequently in my work. /* End of text from uiucdcsp:comp.arch */ The algorithm presented by fouts@orville is not parallizable. As he mentioned, there exist prime finder algorithms that are. In fact, there is a prime finder algorithm that should have linear speedup on a multiprocessor, e.g. the probabilistic one. I would be interested in knowing more about the real problems that come up frequently. Even though this is comp.arch, I will argue that the real problem in building parallel systems is finding the parallel algorithms to run on them. This problem is caused by the fact that we don't have many parallel machines, so we don't spend much time looking for parallel algorithms. The few people who do have those machines are more interested in solving their day-to-day problems then they are in doing research into the fundamentals of algorithms. If we want to make a lot of progress in this area then we will have to fund those people who are doing research in fundamental computer science. This area is woefully underfunded, contrary to popular opinion. By the way, I don't work in inventing algorithms, but I enjoy using the algorithms invented by those who do. Ralph Johnson
fouts@orville.nas.nasa.gov (Marty Fouts) (12/20/87)
In article <76700007@uiucdcsp> johnson@uiucdcsp.cs.uiuc.edu writes: > >Even though this is comp.arch, I will argue that the real problem in >building parallel systems is finding the parallel algorithms to run on them. >This problem is caused by the fact that we don't have many parallel machines, >... I agree. There is also another problem which has to do with theoretical understanding of computational complexity. Algorithm complexity is studied in the frame work of Turing machines, because of the knowledge that a TM can compute anything computable, and the implicit assumption that an algorithm which is optimal on a TM is optimal on a scalar Von Neumann machine. There doesn't appear to be a theoretical framework for studying complexity in machines where different operations cost different amount or where parallization is possible. (Other than taking the plunge into real machine modeling, but there the level of detail makes it difficult to extrapolate to the general case.) It seems to me that some useful work could be done in putting together an algorithm complexity model which would be useful for dealing with a multiple processor application. . . Marty
alex@.UUCP (Alex Laney) (12/23/87)
In article <2602@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > > Just to clarify, it is my opinion that multi-tasking *is* the wave of the > [near] future for micro-computers. All I'm saying is that it isn't a sure > thing. > -- > > Frank Adams ihnp4!philabs!pwa-b!mmintl!franka > Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108 I think what you really mean is OS/2 isn't a sure thing! -- Alex Laney alex@xicom.UUCP ...utzoo!dciem!nrcaer!xios!xicom!alex Xicom Technologies, 205-1545 Carling Av., Ottawa, Ontario, Canada We may have written the SNA software you use. The opinions are my own.
jap@cbdkc1.ATT.COM (12/24/87)
In article <44@amelia.nas.nasa.gov> fouts@orville.nas.nasa.gov (Marty Fouts) writes: >... >I agree. There is also another problem which has to do with >theoretical understanding of computational complexity. Algorithm >complexity is studied in the frame work of Turing machines, because of >the knowledge that a TM can compute anything computable, and the >implicit assumption that an algorithm which is optimal on a TM is >optimal on a scalar Von Neumann machine. There doesn't appear to be a >theoretical framework for studying complexity in machines where >different operations cost different amount or where parallization is >possible. (Other than taking the plunge into real machine modeling, >but there the level of detail makes it difficult to extrapolate to the >general case.) > >It seems to me that some useful work could be done in putting together >an algorithm complexity model which would be useful for dealing with a >multiple processor application. . . Actually there are some formal models for parallelism (including their relationship to sequential models). I just completed a course in Computational Complexity at Ohio State, and in it we studied two such models: Parallel Random Access Machines (PRAMs), and Uniform Families of Circuits. The area seems to be pretty fluid yet (e.g., the professor used a textbook he is in the process of writing, since he wasn't aware of any existing general treatment of the subject), but it is indeed there. [mini-diatribe] Who, pray tell, is the person who made the decision to electronically enforce a limit on the size of quoted material? Somewhere out there, someone made such a conscious decision, making life miserable for those who post. Whoever made this decision owes a public apology to the net, and an immediate retraction of said "feature" from the software. Note that this diatribe was added simply to allow me to post the real message above. [end of diatribe] ------------------------------------------------------------------------------- James A. Parker | This message is both brought to you and disavowed by ...!cbosgd!cbdkc1!jap | AT&T Bell Laboratories -------------------------------------------------------------------------------
aglew@ccvaxa.UUCP (12/25/87)
>[fouts]: >I have written code for the Alliant, and it does a good job of >recognizing concurrency that it can find. How does it do at recognizing concurrency that it cannot find, or finding concurrency that it cannot recognize? :-) (Sorry about that. Merry Christmas All! Joyeux Noe:l `a Tout Le Monde! And an especially Happy New Year wish for all the AIs out there!) Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.