hassell@tramp.Colorado.EDU (Christopher Hassell) (01/08/89)
It appears with all the discussion that has gone on about this stuff that Apple users have become a quiescent lot, content with their place. Actually that is only based on the lack of discussion, it may be that everyone knows what they want. They just want bigger numbers in two slots in their ads... Mhz and Meg right? I personally am tired of waiting for the Mhz fairy to come and save us. Chips are now becoming less dumb and very dense but they ARE approaching a general limit on computibility. Expensive stuff is the only forefront now. New materials and techniques and qualities of gates are the only things keeping innovation going these days <and boy did it go at times!>. As for the Apple stuff, who other than Apple will have a Specific reason to upgrade and *follow* their 65xxx line? What will the "Next Generation"'s preferences be like when they see only Mac's and AT compat's, and then they see that little *overpriced* IIgs sitting there, hmm? Mhz is NOT even a good approximation of the speed of an apple as one poster noted a while ago. It matters only when the general instruction-set is very similar. 65xxx's to a LOT more per cycle and therefore need less. I still don't posit that the 65xxx is near being as speedy as the 80x86 line or especially the 680x0 line. It is *underdeveloped* and losing steam. It is a relic by merely 3 years or so, but it has lost its momentum. I personally see the value in NOT needing the 1st fastest system on the market and the most bang for buck, especially since I don't really need them. But I do have a problem with the non-innovation and disinterest in producing anything worthy of Apple anymore. The amiga is a flawed machine and it is going to surpass Apple's meager expectations as it has before. I ask because I did see a bit of interest in a "People's" petition regarding how to design the IIgs+ or whatever computer, but I didn't see anyone with enough curiosity/tenacity to talk about any criticism to Brother Apple these days. My own design was along the lines of keeping all background tasks to a SECOND processor for the gs design. Quite helpful actually, and would produce a mama of a computer, one even suited to connectivity. <If anyone is interested I can mail them the rather detailed article> I don't think that mere *compatibility* should be the party line we must toe. I know many programmers who think otherwise on that do-what-we-say -so-you'll-be-safe-when-we-get-more-Mhz-later principle. Taking a system to the limit is a *natural* programming technique and should be allowed. I'm sorry if this was a bit flamey, but it is dispersed over everyone who COULD have a say/interest in a better Apple, but doesn't. ### C>H> ###
dnelson@umbio.MIAMI.EDU (Dru Nelson) (01/10/89)
I think you really want to start a flame war :-) in article <5678@boulder.Colorado.EDU>, hassell@tramp.Colorado.EDU (Christopher Hassell) says: > > But I do have a problem with the non-innovation and disinterest in producing > anything worthy of Apple anymore. The amiga is a flawed machine and it > is going to surpass Apple's meager expectations as it has before. > I agree with your first statement. I really disagree with the last. The Amiga is not flawwed; although it is harder to program, you are rewarded with speed and new knowledge. If you would like to get into a debate over the Amiga, do it through the mail. This is still apple's territory and it will stay that way. > I ask because I did see a bit of interest in a "People's" petition > regarding how to design the IIgs+ or whatever computer, but I didn't see > anyone with enough curiosity/tenacity to talk about any criticism to > Brother Apple these days. Where have you been? The whole problem with the GS is the way "Brother Apple" made it. > > My own design was along the lines of keeping all background tasks to > a SECOND processor for the gs design. Quite helpful actually, and would > produce a mama of a computer, one even suited to connectivity. > <If anyone is interested I can mail them the rather detailed article> > > I don't think that mere *compatibility* should be the party line we must > toe. I know many programmers who think otherwise on that do-what-we-say > -so-you'll-be-safe-when-we-get-more-Mhz-later principle. Taking a system > to the limit is a *natural* programming technique and should be allowed. > > I'm sorry if this was a bit flamey, but it is dispersed over everyone > who COULD have a say/interest in a better Apple, but doesn't. I would like to change apple into a company where marketing would take a seat behind "Delivery of power to the user at a low price tag". However, I don't own 51% of apple so there is little chance. 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. > ### C>H> ### -- Dru Nelson UUCP: ....!uunet!gould!umbio!dnelson Miami, Florida MCI: dnelson Internet: dnelson%umbio@umigw.miami.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/10/89)
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).
hassell@tramp.Colorado.EDU (Christopher Hassell) (01/10/89)
In article <9323@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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 <by making the 2nd evvironment> 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.
buyse@concave.uucp (Russell C. Buyse) (01/11/89)
Christopher Hassell writes: >Doug Gwyn (VLD/VMB) <gwyn> writes: > >#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. > >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. I think that you are tossing away the issues of multi-processing too quickly. Devising architectures, system software, and development tools is a much more complex task when you throw parallelism into the formula (perhaps a reference to comp.parallel is in order?). If parallelism had so many built-in advantages with micros, there would be a good deal more of them available that do it. Parallelism is not required for the next Apple II. What is required is much faster scalar execution and enhanced graphics capabilities. These are both well-known quantities that can be produced by Apple Computer. The best way that multiple processors might be utilized would be as it is being done in many micros-- by using processors for individual functions, such as for the keyboard, etc, in order to free the CPU for other tasks. -russ. UUCP: {uiucdcs,sun,uunet,harvard,killer,usenix}!convex!buyse --or-- buyse@convex.COM
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/12/89)
In article <788@convex.UUCP> buyse@concave.UUCP (Russell C. Buyse) writes: >Parallelism is not required for the next Apple II. What is required is >much faster scalar execution and enhanced graphics capabilities. These >are both well-known quantities that can be produced by Apple Computer. Support for multitasking would also be extremely useful. Note that that is a separate issue from multiple processors.
hassell@tramp.Colorado.EDU (Christopher Hassell) (01/15/89)
buyse@concave.UUCP (Russell C. Buyse) writes: #Christopher Hassell writes: #>Doug Gwyn (VLD/VMB) <gwyn> writes: #>#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. #> #>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. # #I think that you are tossing away the issues of multi-processing #too quickly. Devising architectures, system software, and development #tools is a much more complex task when you throw parallelism into the #formula (perhaps a reference to comp.parallel is in order?). If #parallelism had so many built-in advantages with micros, there would be a #good deal more of them available that do it. IBM has shown us that innovation is not necessarily the best business strategy. The processors are not necessarily equivalent in environment, even though that would be nice. Architectures would only require things like locking write-access to I/O and multi-porting RAM in certain places in certain ways. Otherwise very little would need to be done other than package two machines into one. It is their overlap that is powerful but their separateness also helps to simplify things. System software is dealing with two equivalent processors but not two that do the same tasks or work in *completely* similar manners (w/out inherent knowledge regarding which one runs what stuff). With things like that there is very little to worry about in system software except (again) things like write-locking certain stuff, and even then it is *coarse* parallelism so separate memory is very likely. #Parallelism is not required for the next Apple II. What is required is #much faster scalar execution and enhanced graphics capabilities. These #are both well-known quantities that can be produced by Apple Computer. Well, nothing is "required" for the next Apple II. I feel that given the amiga as a competitor, the Apple will still not live up to expectations that are requiring a lot more because of the amiga's example regarding gee-whiz hardware niceties. #The best way that multiple processors might be utilized would be as it is #being done in many micros-- by using processors for individual functions, #such as for the keyboard, etc, in order to free the CPU for other tasks. The advantages I speak of a very similar to the things you suggest *except* that they are all combined into the versitility of a SOFTWARE processor instead of near-hard-wired stuff. Interrupts can help distribute the raw power a second processor would produce. A *plethora* of other things, however are likely, specifically for micros. Paging types of activites are already done but simple lookups and occasional backing up of a memory image <no penalty> are other *very nice* possibilities. Many things regarding the user-interface these days have NO END-SYNCHRONIZATION, that is to say, nearly nothing depends on when some jobs are done. Graphics are one application that quickly comes to mind, along with pre-loading of sound info before it is needed. Other very nice possibilities are that of being able to have a smart end handling things on a network (notification when printing is done, when mail arrives etc...). Many many things can be done with I/O that is not interactive. Studies have shown that ONLY ONE background task is usually required at any time in a working session, with buffers or not. So there they are: Extended Smart I/O stuff, Memory handling, Non-critical jobs, and general versitility are all possible WITHOUT bringing stuff like nice safe multiprocessing in (usable ONLY after multi-tasking has been established). <That is definately a way to make things more complex> Note things that are not provided in this idea are things like n-processor parallelism and complete switchability of processor environments. I still think the benefits would produce a far more useful computer than any based on vaporMhz and most of those on the market today. Please don't anyone consider any of this to be aimed at any people or at any general principles, except that parallelism has been treated like plutonium, and no one has figured out that it is as safe as sunlight if used with as much versitility as is possible. #-russ. #UUCP: {uiucdcs,sun,uunet,harvard,killer,usenix}!convex!buyse # --or-- # buyse@convex.COM ### C>H> ###