Path: utzoo!attcan!uunet!lll-winken!ames!ncar!boulder!tramp!hassell From: hassell@tramp.Colorado.EDU (Christopher Hassell) Newsgroups: comp.sys.apple Subject: Re: Is anyone here interested in the "Future of Apple //?" Message-ID: <5747@boulder.Colorado.EDU> Date: 10 Jan 89 11:43:06 GMT References: <5678@boulder.Colorado.EDU> <1209@umbio.MIAMI.EDU> <9323@smoke.BRL.MIL> Sender: news@boulder.Colorado.EDU Reply-To: hassell@tramp.Colorado.EDU (Christopher Hassell) Organization: (Let's see, I'm positive .. I've got ... ) Lines: 53 In article <9323@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: #In article <1209@umbio.MIAMI.EDU> dnelson@umbio.MIAMI.EDU (Dru Nelson) writes: #>I like your idea about going parallel. I don't like the tools much, #>But if we had a linda tool we could add many more processors and #>really make it zoom. The next step would be to get the developers to #>take advantage... really take advantage of it. # #It may come as a surprise to people who haven't had experience using #parallel processing, but it is hard to exploit multiple concurrent #processors in a reliable, controlled manner. For a handful of CPUs, #probably the best way to use them is in support of a mutiprocessing #environment such as UNIX. There are several "superminis" like this, #and they do make good use of concurrent CPUs without causing #programming nightmares. Developing applications for which the #parallelism is explicitly visible is a mistake, except in certain #specialized cases (for example, we perform parallel ray tracing on #our systems that provide concurrency support, reverting to single- #thread ray tracing on other systems). (ain't it hard sometimes to see a place to cut down on quoted material?) That school of thought has TOO much "common knowledge" for my tastes, sorry. Very coarse grained parallelism is a perfect application for micros, I believe. Oh well. My original idea was more along the lines of a processor that has access to a section of memory, (even some of its own,) and ROM (VERY easy), to the slots, and other I/O areas (control AND graphics/mem). My point was not to go straight-for-the-throat multitasking, which would require some wierd locking and would make old software incompatible. My idea was to allow the Apple to migrate into a newly defined territory, with the 1st processor as the "Compatibility Box" no less. MANY MANY MANY MANY things are possible to put into the background stuff. Basically this is anything that does not need exact synchronizing upon completion. Disk load-ahead and graphics/desktop maintenance were both ideas I thought were likely jobs. The Apple Ideal of everything software-run would also produce jobs to be taken care of like "programmable sprites" (synched to the GS's already made screen-line interrupts). A study has found that only one background task is usually required in ANY case. The new programming environment would make this possible as WELL as the possibility of programming for single-proces- -sor multi-tasking and later-on multiprocessing. The loads mentioned above are ones that I have noted that the Amiga even has rather large problems with. Concurrent programming is NOT that bad as long as the writing bottleneck is avoided at all places where it can come about. A picture perfect environment can be left with processor #1, so nothing truly is lost. I still ask, is more than a very few interested in showing this to Apple? (as if they would listen) If not that does anyone know a specific person that would be good to mail to. I think I'll give it a try myself.