barmar@think.COM (Barry Margolin) (01/01/70)
In article <20164@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: [description of why preemptive multitasking causes long lags when an idle interactive task is restarted] > >Amiga fans can help not by explaining why multi-tasking is good, but >by explaining how the Amiga can do multi-tasking without suffering >from the interactive response problems that plague Unix, VMS, and that >plagued the Lisa. I don't have an Amiga, but I think the reason it doesn't suffer from the problems you describe is that it doesn't page. The problems you described have nothing to do with whether multitasking uses a preemptive or synchronous scheduler. If an inactive task is paged out, there will be a long delay paging it back into memory in either case. And if you have to wait 3-4 seconds for your Sun to restart an inactive process, you must be running some huge applications or you don't have enough memory, as I've never seen a Sun pause that long. Most of the time switching windows seems to be spent redrawing the window (redrawing the previously-hidden parts, fixing up the border objects). Or maybe the Sun 3/50 is smaller than I think (I think most of our Suns here are 3/140's and 3/280's). The main thing that would slow down preemptive multitasking on the Mac is the lack of an MMU. Without this, the system must copy all the low memory globals of one task to somewhere else in memory and then copy in the globals of the new task. With an MMU it can simply adjust the segment registers to point to the new task's globals. Globals common to all tasks (such as screen memory) would be pointed to by a different segment register that wouldn't be updated. Macintosh background tasks simply don't expect to have their own private set of low memory globals. They lock down some space in the all-task common area (currently the system heap), and they are able to run no matter which foreground task is currently in control. If they want to run more often than the foreground task calls GetEvent, they can put themselves on the VBL queue, so they will run as often as 60 times a second. An MMU will soon be available for the Mac II. Initially it will only be used by A/UX. However, I am sure that it won't be too long before someone (Apple, Andy Hertzfeld, someone new) figures out how to use it to make the normal Mac OS have preemptive scheduling. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (01/01/70)
I've been dealing with this by mail (to avoid contributing to the
mcibtyc stuff), but David asked a legit question, which I happen to
have a good answer to.
In article <20164@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
<Virtual memory interacts poorly with time-slicing and interactivity:
<If you have time-slice multitasking, there will often be big low priority
<jobs running in the background, while there is an interactive job
<responding to the user. As the user stops to think, the interactive
<job has nothing to do, so the background job gets most of the CPU. As
<the background job runs, it pages in its working set, and as the
<background job is paged in, the interactive job is paged out.
No, that wasn't the legit question. Just wanted to point out that
swapping systems (say, v6 Unix on a PDP-11/70) have a similar problem.
The interactive jobs get swapped out, and you get that 3-4 second
pause while they load in from disk and restart.
This isn't really a problem of VM vs. multitasking, it's a problem of
overloading the machine. Without VM, those extra tasks will swap
instead of page. Without swapping or vm, those extra tasks just don't
happen (not enough memory to load them).
As you go from fully resident to swapping to vm, you loose a little
performance as you push the macchine to the edge of the capabilities
of the simpler system. But you get performance beyond that edge,
albeit in a degraded mode. Which you want depends on your applications
and budget.
<Amiga fans can help not by explaining why multi-tasking is good, but
<by explaining how the Amiga can do multi-tasking without suffering
<from the interactive response problems that plague Unix, VMS, and that
<plagued the Lisa.
That was the legit question. I don't know about the LISA, but I can
explain why the Amiga does a lot better than Unix or VMS. Both Unix
and VMS have floating priority for processes. This attempts to see
that each process gets a fair (however you define fair) portion of
cpu. To do this, you have to recalculate the priorities every so
often. You also have to keep track of the amount of CPU time each
process eats, etc. All of this gets expensive.
On the other hand, the amiga keeps a fixed priority for each task. All
that overhead vanishes. Of course, the user has to do some work on
setting priorityies for his tasks, but that's nominal most of the
time.
As for pauses & etc. bothering you on Unix & VMS, you ought to run on
a well-tuned unix or VMS system, carrying a reasonable load. It's
quite different than you find running either on the typical university
machine, or on a system out of the box.
BTW, claiming that it was the multi-tasking that killed the Lisa (aka
the Mac XL) seems to be a bit of post hoc, ergo propter hoc. After
all, Apple had another machine die in that same time frame, and it
wasn't multitasking. I suspect that pricing had more to do with either
than multitasking or lack thereof.
<The Macintosh has always had event-driven multi-tasking, as opposed to
<time-slice. I have written many programs that run as background tasks.
<It is just that on the Mac, the interactive application must
<explicitly give up control (which it only does at times that are not
<critical to the perception of responsiveness.) All the major Macintosh
<applications do give up control to background tasks. To see this, run
<my "Menu Clock". If the colon between the hour and the minutes display
<blinks, then the application is giving up control to the clock.
Comes the $64 question: Does all include C compilers waiting on disk
IO, and similar things?
Also does your menu clock have any magic code because it's a
background application? My Amiga menu clock doesn't - it's just a
stock application, no magic at all.
<mike
--
Round about, round about, in a fair ring-a. Mike Meyer
Thus we dance, thus we dance, and thus we sing-a. mwm@berkeley.edu
Trip and go, to and fro, over this green-a. ucbvax!mwm
All about, in and out, over this green-a. mwm@ucbjade.BITNETalan@pdn.UUCP (Alan Lovejoy) (01/01/70)
In article <7115@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > >Anyone that says "Multitasking would not be useful on a Mac anyway" >has obviously not used an Amiga for any length of time! It's awfully >nice to be able to unarc and look through sources while the transfer >of another is going on. And all the while, a 24 hour raytrace is >making good use of those extra cpu cycles. I do it all the time. >Of course, if you never have because your computer can't do it, you >probably don't know what you're missing. > >Vive la Amiga! > Having used both the Mac and the Amiga, I feel competent to comment on this. Multitasking on the Amiga is DEFINITELY useful. The type of program that could make effective use of multitasking on the Mac is not commonly available. Most Mac programs expect to interact with the user--including those that on the Amiga are written to detect whether they are running in foreground or background and act accordingly. Until Mac programs have had a chance to take multitasking into account, its utility on the Mac is considerably less than on the Amiga. Of course, the same obtains on most microsystems (e.g, the MSDOS systems) to varying degrees. --Alan "Wants a Mac II, works on a PC's LTD 386, owns a Stride" Lovejoy
lishka@uwslh.UUCP (Christopher Lishka) (01/01/70)
In article <20164@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Most Macintosh owners who read these news groups have a perfectly good >idea what multi-tasking is. Agreed, and it too hard to try and explain multitasking to someone without showing it on a machine. However, sometimes I am very surprised at how many people don't know how to use multitasking on Un*x. >Now some substance: Most time-slice mutlti-tasking operating systems >guarantee that every ready-to-run job will get a chance to run, at >least once a time-interval (often a second.) This has the effect of >slowing down interactive performance: the interactive application >doesn't get all of the processor, so there is a lag in its response to >user input. Time sharing multi-user operating systems (like Unix) are >built on the premise that the user will ignore the lag. But, users >used to a single process environment get very picky about the fine >time structure of responsiveness. Example: "If it used to begin to >respond in 3/5ths of a second, and now it takes 4/5ths of a second, >even if it finishes in half the old time, it will feel sluggish." Hmmm...from what I've heard, Un*x's time slice was changed from around 1 second to a lower figure in one of the recent BSD releases, to fix problems like you have described. Anyways, it is true that if you use vanilla time-slicing you find a lag in interactive response if you run more jobs. However, a good priority scheme can alleviate this problem...something like a well-tuned exponential queueing system. However, the key note is that multitasking needs to be well tuned to the machine and purpose. Blanket statements like "Multitasking *always* works well" or "I don't ever want to use multitasking because it slows down interaction" just don't cut it. We are running on a VAX-11/750, and at times have 31 users on it (ouch!). Now, the machine *does* slow down, but because what most of the users are doing is NOT so CPU intensive, one can still work reasonably well on the machine. Of course, the machine will work much nicer if there is only one user on it (me, after everyone else has gone home ;-) . >Here is a problem that neither the current Mac or Amiga have, but may >hurt them both in the future: >Virtual memory interacts poorly with time-slicing and interactivity: >[ Mr. Oster goes on to describe problems with Virtual Memory/Disk > Swapping and Time-slicing ] This is certainly true *if* there is not enough RAM to store the program in memory while the others are running. *However*, given a reasonably good amount of available RAM, the running program will not need to swap out to disk nearly as much. This is helped by the 10%-90% principle (10% of the code runs 90% of the time). Another example: we here at the State Lab have around 8 megabytes of RAM. When I last discussed disk-swapping with our local Un*x-wizard, he told me that we rarely get swaps out to disk because of the 8 megabytes of RAM we have installed (and by rarely I mean that he has only seen the system swap a few times in all of the time he has [visually] monitored it). Like I alluded to above, we run a fairly loaded system. But because of a relatively small investment in a lot of RAM, the system is working close to its peak level. My point is that if you implement virtual memory *or* time-slicing poorly, you will get poor results. If you implement it properly you get good results. Maybe that is why the Amiga does not have virtual memory...there would be too much overhead involved (in hardware and software) to warrant the current need (someone told me about software-implemented virtual memory in Micr*soft Windows, saying he works with it and it is really slow, even on his AT). That is also a good reason (maybe) why Apple didn't include a Multitasking system when they built the Macintosh; it wasn't working well with the Lisa so they decided that they would pass over multitasking in favor of a lower price tag. However, that does not excuse the fact that Apple does not have Multitasking on its Macintoshes now. Multitasking (as proven by the Amiga and other machines such as the AT&T 6300+) is a very realizable goal for personal computers *if*you*do*it*right* ! With the older Macintoshes it wasn't, because as Mr. Oster points out there was not enough memory. But it could be a real goal for current Macintoshes (I think, although I am not sure). The only drawback now is the current Operating System, which is a big drawback. I don't think that what Apple is currently calling "Multitasking" is true multitasking (i.e. you have to switch between processes yourself!). Note that Apple *is* getting true Multitasking with their Mac II's, and IBM is getting it with their OS2's...multitasking is finally coming of age (and the Amiga has had it for a couple years already!). >Amiga fans can help not by explaining why multi-tasking is good, but >by explaining how the Amiga can do multi-tasking without suffering >from the interactive response problems that plague Unix, VMS, and that >plagued the Lisa. Correct...multitasking is another one of those damned religious issues such as editors or "my computer whips your computer's b*tt!", (or the Pixar debate) that are best left in one newsgroup, and not cross-posted to annoy other newsgroups. [Personally, I don't think that Un*x has that bad of an interactive problem...I've become quite content with it, and prefer the ability to run many programs, along with my fellow workers, than to have a dedicated IBM PC in front of...you can't email very well with an IBM!] >--- David Phillip Oster --My Good News: "I'm a perfectionist." >Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour." >Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edu -Chris -- Chris Lishka /lishka@uwslh.uucp Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu \{seismo, harvard,topaz,...}!uwvax!uwslh!lishka
gary@eddie.MIT.EDU (Gary Samad) (08/14/87)
I just came back from MacExpo here in Boston and saw their new "Multifinder" "first generation multitasking" system. They really have no right to call this thing multi-tasking. It gives you print-spooling (even the lowly PeeCee has print-spooling) and the ability to have several programs open at once (if they're compatible with Multifinder) but they do NOT run at the same time unless the program makes "give-up-the-CPU calls" frequently! That's right, no time slicing whatsoever. This is really a joke! There are no provisions whatsoever for process spawning, inter-task communication, or, it appears, even dynamic memory allocation (it appeared that each program was allocated a fixed ammount of memory, out of which it could allocate what it needed). I wonder if Apple is really going to pull the wool over its user's eyes by advertising "The new Mac multitasking operating system." Gary
wetter@tybalt.caltech.edu (Pierce T. Wetter) (08/14/87)
In article <6565@eddie.MIT.EDU> gary@eddie.MIT.EDU (Gary Samad) writes: >I just came back from MacExpo here in Boston and saw their new "Multifinder" >"first generation multitasking" system. They really have no right to call >this thing multi-tasking. It gives you print-spooling (even the lowly PeeCee >has print-spooling) and the ability to have several programs open at once >(if they're compatible with Multifinder) but they do NOT run at the same time >unless the program makes "give-up-the-CPU calls" frequently! That's right, ^^^^^^^^^^^^^^^^^^^^^ This is otherwise known as Dosystick which is called when the current program is idle i.e. when a background process is waiting for input it doesn't take up time. Personally, since most mac programs require so much feedback I can't see where MultiTasking would be useful except in printspooling and telecomm stuff. Presently, I am running on a multitasking system and I acutally wish it wasn't since it annoys me to have to wait while the computer catches up with my typing. Additionally, because of the large quantities of information which have to be swapped around (namely all the lowmemory globals) multi tasking is impractical without an MMU (Unix gets around this by swapping things off and on the hard disk KLUDGE!!!!!!). When Apple releases MultiFinder as a full MultiTasking system it will probably only time-slice on the MacII with a PMMU. >There are no provisions whatsoever for process spawning, inter-task >communication, or, it appears, even dynamic memory allocation (it appeared >that each program was allocated a fixed ammount of memory, out of which it >could allocate what it needed). InterTask communication in a graphical interface? Not practical for two programs to communicate with each other that way. However, if a program wants to spawn subprocesses the mac has always had that capability it's called the vertical retrace queue. Actually the Mac does have intertassk comm. Read Inside Mac volume V, specifically the Notification Manager. Again dynamic memory allocation is impractical without an MMU unless you wish to have processes writing into each others memory (wouldn't it be lovely if every time a program in Unix crashed it brought down everyone else too?) >I wonder if Apple is really going to pull the wool over its user's eyes by >advertising "The new Mac multitasking operating system." > Well, since it won't be out until September we'll have to see won't we. However, isn't allowing print-spooling and telecomm in background multi-tasking? What is the practical purpose in running dark castle and MacDraw at the same time since they both require continuous input? FLAME ON I notice in the message header that you are posting to both the amiga and mac newsgroups. Why? If you are a Mac user why are you bothering the amiga owners with mac news? if you are an amiga user why are you posting mac news since you probably don't know enough about the mac for your comments to be relevant anyways? Regardless why do amiga people care about MultiFinder? FLAME OFF PIerce Wetter Brooke's Law: Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition. -------------------------------------------- wetter@tybalt.caltech.edu --------------------------------------------
tim@hoptoad.uucp (Tim Maroney) (08/14/87)
MultiFinder version 1 does not have time-slicing. However, it will in the
future. In any case, since Mac programs are so heavily interface-driven,
time-slicing is not a particularly great requirement.
--
Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)walton@tybalt.caltech.edu.UUCP (08/14/87)
In article <2742@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >MultiFinder version 1 does not have time-slicing. However, it will in the >future. In any case, since Mac programs are so heavily interface-driven, >time-slicing is not a particularly great requirement. You mean if I want to do some editing while Mac C Kermit is downloading a 150K file for me at 1200 baud, I have to go to another machine? I can't type "make" in a CLI window and then go off and play a game? Humph... Look, can we all agree that it was unfair of Gary Samad to tweak the Mac owners about their lack of multitasking, AND that the Mac defenders' postings so far (Tim Maroney's and Pierce Wetter's) show little understanding of the Amiga's capabilities? Let's nip this thing in the bud before the net explodes with another religious war. Steve Walton, guest as walton@tybalt.caltech.edu AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu "Long signatures are definitely frowned upon"--USENET posting rules
curry@nsc.nsc.com (Ray Curry) (08/14/87)
The Apple people I am talking too are being very careful about refering to the new finder as a background tasker. Initially the print spooler will be the only thing programmed to be used thusly. Other programs are on the way from second party people. It's the press in their usually uninformed and ignorant rampages that are calling it multitasking. Let's not blame Apple for the problems of the press.
page@ulowell.UUCP (08/14/87)
Yes, it was a cheap shot for Gary to include comp.sys.mac in the
distribution line. However, I agree with what he said, and was
pretty amazed by the comments from the other camp.
Gary asked if Apple really thought they could pull the wool over
their user's eyes. The responses "multitasking isn't very useful"
clearly shows that Apple has already done that.
Color isn't very useful either, I imagine.
..Bob
PS Can you IMAGINE what the Amiga would be like if Commodore could
have a marketing organization as good as Apple's? Neither can I.
--
Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} lishka@uwslh.UUCP (Christopher Lishka) (08/14/87)
In article <6565@eddie.MIT.EDU> gary@eddie.MIT.EDU (Gary Samad) writes: > >I wonder if Apple is really going to pull the wool over its user's eyes by >advertising "The new Mac multitasking operating system." > > Gary Hey, I for one would not be surprised. Most (in my opinion) people do not know what multitasking is, so you could say "this Commodore 64 over multitasks because it can have two programs in memory at once and switch between the two!" and the person would believe that this is true multitasking. There belief is certainly not out of stupidity, but rather out of a lack of proper information. Hell, when all one has ever used has been a PC or CPM or an Apple (or some such single tasking computer), it is not suprising that one does not know what true multitasking really is. Most users of PC's are not educated in computer science, let alone the internals of Operating Systems, so I think it is perfectly reasonable that they would not understand what multitasking is, and that *YES*, Apple will pull the wool over the eyes of PC and Apples users. However, they will NOT pull the wool over UNIX users' or Amiga users' eyes! -Chris -- Chris Lishka /lishka@uwslh.uucp Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu \{seismo, harvard,topaz,...}!uwvax!uwslh!lishka
czei@osupyr.UUCP (Michael S Czeiszperger) (08/16/87)
In article <6565@eddie.MIT.EDU> gary@eddie.MIT.EDU (Gary Samad) writes: >I just came back from MacExpo here in Boston and saw their new "Multifinder" >"first generation multitasking" system. They really have no right to call >this thing multi-tasking. > >I wonder if Apple is really going to pull the wool over its user's eyes by >advertising "The new Mac multitasking operating system." > > Gary It's not true Multitasking; that's why its called Multifinder. Since all Macintosh users know what the finder is, and what multi means, the name Multifinder correctly describes the new product. It's just many copies of the finder running at the same time. It really isn't practical to have most mac programs running at the same time because they are so user dependant. If there isn't someone clicking a mouse they don't do anything. If users want true multitasking they'd buy an Amiga. Michael S. Czeiszperger | Disclaimer: "Sorry, I'm all out of pith" Sound Synthesis Studios | Snail: Room 406 Baker Phone: (614) College of the Arts Computer Lab | 1971 Neil Avenue 292- The Ohio State University | Columbus, OH 43210 0895 UUCP : {decvax,ucbvax}!cbosgd!osupyr!czei
czei@osupyr.UUCP (Michael S Czeiszperger) (08/16/87)
In article <3638@cit-vax.Caltech.Edu> walton@tybalt.caltech.edu.UUCP (Steve Walton) writes: >In article <2742@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >You mean if I want to do some editing while Mac C Kermit is downloading >a 150K file for me at 1200 baud, I have to go to another machine? I >can't type "make" in a CLI window and then go off and play a game? >Humph... Well, that's not really true. I have a desk accessory called 'backdown' for my mac which will download in the background while the finder is running. During the download I can play any game I feel like, even Hack. (Oh yeah. And don't flame me for being a mac owner posting on the Amiga board, because I work for OSU's department which is responsible for both Amiga's and Mac's - I have to be familiar with both. So there.) Michael S. Czeiszperger | Disclaimer: "Sorry, I'm all out of pith" Sound Synthesis Studios | Snail: Room 406 Baker Phone: (614) College of the Arts Computer Lab | 1971 Neil Avenue 292- The Ohio State University | Columbus, OH 43210 0895 UUCP : {decvax,ucbvax}!cbosgd!osupyr!czei
tim@hoptoad.uucp (Tim Maroney) (08/16/87)
In article <3638@cit-vax.Caltech.Edu> walton@tybalt.caltech.edu.UUCP (Steve Walton) writes: >>In any case, since Mac programs are so heavily interface-driven, >>time-slicing is not a particularly great requirement. > >You mean if I want to do some editing while Mac C Kermit is downloading >a 150K file for me at 1200 baud, I have to go to another machine? I >can't type "make" in a CLI window and then go off and play a game? >Humph... Well, as long as the downloading loop cedes control of the processor every time through, a trivial code change, then synchronous multitasking will serve this end quite well. I'm not clear on how MultiFinder handles modal dialogs (the documentation we've been seeded with is rather deficient), but I believe it will let you change context during them. Anyway, it's pretty easy to make the download run in the background. The same goes for any other special-purpose long-lived operation, like Save; but most of what you do on the Mac doesn't make any sense in the background. That's why I said that time-slicing is not such a big deal. By the way, since games consume most of the CPU on the Mac, I really doubt that you particularly want to slow down your compiles and screw up your game's timing that way. > Look, can we all agree that it was unfair of Gary Samad to tweak the >Mac owners about their lack of multitasking, AND that the Mac >defenders' postings so far (Tim Maroney's and Pierce Wetter's) show little >understanding of the Amiga's capabilities? Let's nip this thing in the >bud before the net explodes with another religious war. I understand multitasking perfectly well, having rewritten a synchronous multitasking system on the Mac, gotten a good way into writing an asynchronous one before my boss insisted I do something useful, and munged around extensively in the UNIX kernel. I don't think you understand the Mac very well, frankly. You don't need time-slicing with a notebook and pen, and for 95% of the things on the Mac you don't need it, either. For the remaining 5%, MultiFinder makes it pretty easy to write them so they can run in the background, even in current versions. No coroutines, asynchronous notifications, or other weird code structures, just periodically giving up control of the processor. For something like a download or save, it ought to be nearly trivial. For computation-intensive processing, presumably you don't want to slow things down to that extent anyway, whether through synchronous or asynchronous interruptions. -- Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (08/16/87)
In article <2758@hoptoad.uucp>, Tim Maroney (tim@hoptoad.UUCP) responded to comments by Steve Walton (walton@tybalt.caltech.edu.UUCP), who was in turn responding to an article by Tim. In article <3638@cit-vax.Caltech.Edu>, Steve wrote: >> You mean if I want to do some editing while Mac C Kermit is downloading >> a 150K file for me at 1200 baud, I have to go to another machine? I >> can't type "make" in a CLI window and then go off and play a game? >> Humph... Tim's response began: > Well, as long as the downloading loop cedes control of the processor every > time through, a trivial code change, then synchronous multitasking will > serve this end quite well. I'm not clear on how MultiFinder handles modal > dialogs (the documentation we've been seeded with is rather deficient), but > I believe it will let you change context during them. Anyway, it's pretty > easy to make the download run in the background. The same goes for any > other special-purpose long-lived operation, like Save; but most of what you > do on the Mac doesn't make any sense in the background. That's why I said > that time-slicing is not such a big deal. The important point about time-slicing is that it allows virtually *any* two (or more) programs to multitask WITHOUT requiring even one "trivial code change." Thus, on a system with time-slicing, a Kermit download will co-operate with an editor quite nicely (especially if Kermit is running at a lower priority). The editor will suffer no response degradation, while Kermit will run quickly almost all the time (editors usually spend a lot of time waiting for keystrokes. . .). Another example of such an operation, involving four simultaneously- executing programs interconnected by pipes, was mentioned a while back. In UNIX notation, the operation would be (approximately): % kermit -k | uudecode | uncompress | tar xvf - On the Amiga, pipes are named, so the syntax of the command would be different, but the operation is similar. With the (4K byte) pipe files assigned to RAM:, only the output files are written to floppy. As you can imagine, this provides a dramatic increase in throughput over: % kermit -k archive.tar.Z.uu (writes to floppy) % uudecode archive.tar.Z.uu (reads from and writes to floppy) % uncompress archive.tar.Z (reads from and writes to floppy) % tar xvf archive.tar (reads from and writes to floppy) The time savings from eliminating three enormous writes to disk and three correspondingly enormous reads from disk are tremendous. Also, on small systems, there may not be enough mass storage to hold all the intermediate forms at once. Thus, the user would have to delete intermediate files between steps, or operate from one disk to another (or both!). On my Amiga, which has two floppy disk drives and no hard disk, this would tie up the system completely, as well as requiring my intervention at several places in the process. But with the pipelined version, I would need to use only one disk (for output), so the second drive is freed for other purposes. Further, because of the multitasking, I can still do a compilation in the background *and* edit a file while all this is going on! (This assumes that I have boatloads of memory, of course. . .) With process priorities chosen carefully (e.g., editor priority > download, etc. priority > compilation priority), the editor will be responsive, the download and associated processing will perk right along (limited mainly by the phone line data rate), and the compilation will use up whatever is left of the CPU. This is just one example of enhanced productivity and system utility provided by true multitasking. None of the programs that are running need to know or do anything out of the ordinary in order to multitask. Because it puts the responsibility for task switching on the programs themselves, so-called "synchronous multitasking" only works with programs designed to permit task switching. Compared to true multitasking, "synchronous multitasking" is a feeble and limited technique. Having said all this, I am not about to climb upon my soapbox and proclaim the superiority of the Amiga over the Mac. The ideas that underlie the Amiga operating system come from UNIX and other operating systems. I am confident that, in time, true multitasking will be available on the Mac as well. Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever
farren@hoptoad.UUCP (08/17/87)
In article <2758@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > You don't need time-slicing with a notebook and pen, >and for 95% of the things on the Mac you don't need it, either. For the >remaining 5%, MultiFinder makes it pretty easy to write them so they can run >in the background, even in current versions. [...] >For computation-intensive processing, presumably you >don't want to slow things down to that extent anyway, whether through >synchronous or asynchronous interruptions. An example: I had a job which required a large amount of analysis on a huge (20+ Megabyte) data set. The particular analysis required pretty much forced an incremental analysis; that is, the results of the first analysis were fed as input to the secondary analysis processes, and the results of those to the third, etc. There were about eight iterations required for the complete analysis, and the intermediate results, when totaled, occupied considerably more than 50 Megabytes. There was also the problem that each of the analysis steps needed to be checked for accuracy, and due to timing constraints, these checks pretty much had to be made against the original data. The way I did it was to run each analysis step as a sub-process, checking it's output for correctness, and then piping that output to the next series of analyses, once the particular analysis had been made correct. Without the ability to run ALL of the currently correct analysis steps in parallel, while simultaneously editing, recompiling, and checking the analysis sub-programs, the task would have taken much, much longer than it did, not to mention taking up much more of the disk space than I was allocated. The value of true multi-tasking is simply that most programs are NOT particularly CPU intensive, but spend large amounts of time waiting for I/O. Given this, what conceivable value can there be in allowing an I/O bound process to hang up the entire system? Or, for that matter, requiring the program itself to determine when it is safe to let the system run another process? That's just a slightly more sophisticated version of busy-waiting, and strikes me as a BIG waste of useful processor time. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
gary@eddie.MIT.EDU (Gary Samad) (08/18/87)
In article <4558@nsc.nsc.com> curry@nsc.UUCP (Ray Curry) writes: }The Apple people I am talking too are being very careful about refering to the }new finder as a background tasker. Initially the print spooler will be the }only thing programmed to be used thusly. Other programs are on the way from }second party people. It's the press in their usually uninformed and ignorant }rampages that are calling it multitasking. Let's not blame Apple for the }problems of the press. No, it was in the Apple booth where I saw this software demonstrated and on the wall directly above the machine that was being used it said: "The first generation multitasking system" This was not the press.
sean@ms.uky.edu (Sean Casey) (08/18/87)
In article <4537@videovax.Tek.COM> stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: > % kermit -k | uudecode | uncompress | tar xvf - > >The time savings from eliminating three enormous writes to disk and three >correspondingly enormous reads from disk are tremendous. Also, on small >systems, there may not be enough mass storage to hold all the intermediate >forms at once. Steve missed another advantage of this. While one or more of these programs is waiting on I/O, another can be using the CPU. Thus one of the major advantages of multitasking. Two non-cpu bound programs run simultaneously use less real time than if they are run serially. Using resources in parallel is more efficient. Since the amiga doesn't have VM, you're not going to have many thrashing problems. I do wish they'd sort floppy accesses. The poor floppy beats itself to death when two processes try to use it at the same time. Anyone that says "Multitasking would not be useful on a Mac anyway" has obviously not used an Amiga for any length of time! It's awfully nice to be able to unarc and look through sources while the transfer of another is going on. And all the while, a 24 hour raytrace is making good use of those extra cpu cycles. I do it all the time. Of course, if you never have because your computer can't do it, you probably don't know what you're missing. Vive la Amiga! -- -- Sean Casey sean@ms.uky.edu, {uunet,cbosgd}!ukma!sean -- (the Empire guy) sean@ms.uky.csnet, sean@UKMA.BITNET -- "I...am a shrubber..." -- Roger the Shrubber
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/19/87)
Most Macintosh owners who read these news groups have a perfectly good
idea what multi-tasking is. After all, the software that hosts "news"
generally runs on big, multi-tasking machines. So, Amiga owners, you
don't have to keep explaining how wonderful it is.
Now some substance: Most time-slice mutlti-tasking operating systems
guarantee that every ready-to-run job will get a chance to run, at
least once a time-interval (often a second.) This has the effect of
slowing down interactive performance: the interactive application
doesn't get all of the processor, so there is a lag in its response to
user input. Time sharing multi-user operating systems (like Unix) are
built on the premise that the user will ignore the lag. But, users
used to a single process environment get very picky about the fine
time structure of responsiveness. Example: "If it used to begin to
respond in 3/5ths of a second, and now it takes 4/5ths of a second,
even if it finishes in half the old time, it will feel sluggish."
Here is a problem that neither the current Mac or Amiga have, but may
hurt them both in the future:
Virtual memory interacts poorly with time-slicing and interactivity:
If you have time-slice multitasking, there will often be big low priority
jobs running in the background, while there is an interactive job
responding to the user. As the user stops to think, the interactive
job has nothing to do, so the background job gets most of the CPU. As
the background job runs, it pages in its working set, and as the
background job is paged in, the interactive job is paged out. Now the
user starts typing or mousing again. The interactive job must be
retrieved from the paging disk, and the user has to wait for that disk
before his clicks are responded to. On a Sun 3/50 running X and Unix,
this process can take 3 or 4 seconds. That is, clicking on a different
window can mean a pause of as much as 3 or 4 seconds before the new
window is ready to listen to key-strokes (Until it is ready, X will
send the keystrokes to the old active window.)
Pauses, lags, and unpredictable response time all contribute toward
making even a fast system seem slow. Apple had a multi-tasking
operating system back in '81. It was called the "Lisa Office System",
and suffered from all of the responsiveness problems I've outlined.
Amiga fans can help not by explaining why multi-tasking is good, but
by explaining how the Amiga can do multi-tasking without suffering
from the interactive response problems that plague Unix, VMS, and that
plagued the Lisa.
The Macintosh has always had event-driven multi-tasking, as opposed to
time-slice. I have written many programs that run as background tasks.
It is just that on the Mac, the interactive application must
explicitly give up control (which it only does at times that are not
critical to the perception of responsiveness.) All the major Macintosh
applications do give up control to background tasks. To see this, run
my "Menu Clock". If the colon between the hour and the minutes display
blinks, then the application is giving up control to the clock.
The new announcements of multi-tasking by Apple, are beacuse the new
Macintoshes, unlike the 128K original Macs, have enough memory that
more than one interactive application can comfortably reside in main
memory at once. Apple has used the old give-up-control mechanism,
already built into most Macintosh applications, to let applications
give up control, not to small background tasks, but to each other.
Since we already could cut and paste between applications, this means
that the user can pick a group of applications and have them work as a
seamless whole.
--- David Phillip Oster --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.edurichard@gryphon.CTS.COM (Richard Sexton) (08/19/87)
In article <20112@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU.UUCP (Michael Robinson) writes: >In article <3632@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) writes: >[lots of bogus stuf about multi-tasking] >> InterTask communication in a graphical interface? Not practical for >>two programs to communicate with each other that way. > >Can he SAY that???!!!! >Mike Robinson USENET: ucbvax!ernie!robinson Sure. But with a straight face ? Besides, he didnt say it wasnt possible, he said it wasnt practical. Maybe on a mac thats true. The program I wrote *seems* to be doing just that though, behind my terminal emulator screen yet. Sigh. -- Richard Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the key in my ignition..."
daveh@cbmvax.UUCP (Dave Haynie) (08/19/87)
in article <20164@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) says: > Amiga fans can help not by explaining why multi-tasking is good, but > by explaining how the Amiga can do multi-tasking without suffering > from the interactive response problems that plague Unix, VMS, and that > plagued the Lisa. That's a fair question. First of all, we're not talking about a multi-tasking system that swaps out stuff to disk. I've personally run into the effect you're talking about on our Apollo systems. The Apollo systems here have typically a megabyte or two of real memory, and they run very large programs. The Amiga in my office, on the other hand, has seven megabytes of real memory, and runs small and medium sized programs, all of which can share run-time libraries. Real memory at this point is nearly as cheap as mass storage, so I'm very unlikely to need swaps out to disk. That takes care of the largest interactive response problem. It's also a single user machine, not multiuser like a UN*X machine. And the OS does a few things based on this that might not be implemented in an OS for multiple users like UN*X or VMS. Task scheduling is based on fixed task priorities. Higher priority tasks always get all the CPU time they need. Whatever is left gets passed down to lower priority tasks. So, providing you run your interactive tasks at a higher priority than your background tasks, everything's cool. Your interactive stuff is always going to run at full speed while you're interacting with it, and your background tasks get all the CPU time that's free when you stop to think about what to type next. If you run multiple interactive tasks, those that you're not interacting with just go to sleep waiting for your attention once again; they take up no time while just waiting for user input. How well this works, of course, somewhat dependent on programmer's using the proper system calls for things. If I have a task that wants to interact with the Intuition system, let's say, the proper thing to do is set up intertask signals, and then Wait() for them, something like Wait(sigregister & SIGBIT). If I instead wrote while (! (sigregister & SIGBIT)); I would certainly waste lots of available CPU time. It sounds like similar clean waiting stuff is being put into the Mac OS; there's no reason it shouldn't be able to benefit from similar things. > The Macintosh has always had event-driven multi-tasking, as opposed to > time-slice. I have written many programs that run as background tasks. > It is just that on the Mac, the interactive application must > explicitly give up control (which it only does at times that are not > critical to the perception of responsiveness.) All the major Macintosh > applications do give up control to background tasks. To see this, run > my "Menu Clock". If the colon between the hour and the minutes display > blinks, then the application is giving up control to the clock. I run my background clock just as any other program, only at a lower priority. Whever it does something, like update it's display or jump to the front of the window stack, it's doing it while my interactive program is waiting on something (usually me or the disk). The responsiveness of the user interface is also based on task priorities; the program I'm interacting with is higher than the clock, and the Intuition and input programs that manage everyone's menus, keyboard, or mouse input are higher than the interactive program, so you don't see the mouse get sluggish or miss keystrokes even when the system starts getting loaded. > --- David Phillip Oster --My Good News: "I'm a perfectionist." -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "I'd rather die while I'm living, than live while I'm dead" -Jimmy Buffett
kim@amdahl.amdahl.com (Kim DeVaughn) (08/21/87)
In article <6596@eddie.MIT.EDU>, gary@eddie.MIT.EDU (Gary Samad) writes: > > No, it was in the Apple booth where I saw this software demonstrated and on > the wall directly above the machine that was being used it said: > > "The first generation multitasking system" > > This was not the press. First, note that I've edited the Newsgroup line to restrict this to comp.sys.amiga, not wishing to add fuel to still smouldering fires. But ... It seems like this is an opportunity for CBM to do some education through their (still mythical) advertising campaign. You know ... show the customer what *real* multitasking is and can do for them. Maybe hang out a banner proclaiming "Third generation multitasking", or some such. Of course the way things seem to be going these days, it may well be that Apple will claim that "multitasking" is a Trademark or Copyright of theirs ... 1/2 :-) ! This concept is hereby released to Public Domain. /kim P.S. Anybody (CATS, etc.) know when this advertising blitz is supposed to begin? -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
elg@killer.UUCP (Eric Green) (08/22/87)
in article <3632@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu (Pierce T. Wetter) says: > Regardless why do amiga people care about MultiFinder? Well see, it's simple. It's because MultiFinder looks so lame compared to the Amiga Exec, which slices, dices, time-shares, and message-passes, with complete dynamic memory allocation amongst tasks. And you can bet purty as ya please that Apple is gonna advertise it as a REAL multi-tasking operating system, thus pulling the wool over folk's eyes when it comes time to buy a multi-tasking computer and they found they bought a lemon compared to the competition. After all, co-processes giving up control to each other do NOT equal a message-passing multi-tasking kernal... In other words, Apple is engaged in a campaign of deception, and those of us lucky enough to have the real thing, get pretty peeved at their unethical conduct in doing so... By the way, if you have never heard of what a multi-tasking message-passing kernel is, go ask CMU about their MACH Unix-kernel replacement, or go read Andrew Tannenbaum's new operating system book, where he presents the kernel of Minix, his little Unix clone.... As for multi-tasking, how for this scenario: I talk to this Unix system with my terminal. Meanwhile, in another window, me C compiler be churning away, and in yet nother window, a text editor sits (a text editor, no teeny little desk gadget dere), and finally, a shell window be open so I coul pull up the directory to find the name of a file I want to upload in a few minutes... meanwhile, whenever I hit a key, I'm sure not getting any delay -- if your Unix system gives a delay, it is VERY badly tuned, or else SEVERELY overloaded or with insufficient hardware. -- Eric Green elg%usl.CSNET Ollie North for President: {cbosgd,ihnp4}!killer!elg A man we can believe (in). Snail Mail P.O. Box 92191 Lafayette, LA 70509 BBS phone #: 318-984-3854 300/1200 baud
elg@killer.UUCP (Eric Green) (08/22/87)
in article <20164@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) says: > Most Macintosh owners who read these news groups have a perfectly good > idea what multi-tasking is. After all, the software that hosts "news" > generally runs on big, multi-tasking machines. So, Amiga owners, you > don't have to keep explaining how wonderful it is. Unix is only barely multi-tasking. Unix multi-tasking is basically just an afterthought thrown in to answer the question "There has GOT to be a better way to do background jobs than the way Multics does them!" (note that Unix started out as a Multics knock-off -- I have used Multics before, and background jobs are a pain in the a$$ with Multics). Berkely BSD4.2 is a bit more multi-tasking than Sys V, because you can pop jobs to and from the background. Shells running inside of Emacs and Jove windows is even closer, because you can then even interact with two programs at one time. Still, it's nothing compared to a real windowing interface on a bit-mapped screen... hmm, you say you use a Sun, so you should know that (altho I bet that your Sun is underequipped -- probably not enough memory, and slow disk drives, makin paging painful). > Now some substance: Most time-slice mutlti-tasking operating systems > guarantee that every ready-to-run job will get a chance to run, at > least once a time-interval (often a second.) This has the effect of > slowing down interactive performance: the interactive application > doesn't get all of the processor, so there is a lag in its response to > user input. Note that other process's usage of CPU time has nothing to do with response time... they only use CPU time when you're not typing, when you're typing, you have all of the CPU (because each character generates an exception and task switch to your process). It's task switch latency that is the problem. While Unix and most other mainframe OS's have a LOT of state to switch at process switch time, AmigaDOS basically just has to swap in the new registers and new program counter (no MMU setup, etc). On a single-user system, with your interactive processes set to a higher priority than your background processes (e.g. "C" compile), there IS no delay (try typing faster than the task switch latency on an Amiga -- it just ain't done). In multi-tasking terms, Amiga processes are VERY "light-weight". In other words, AmigaDOS is not Unix, and just because heavily-loaded Unix systems are slow to respond, doesn't mean that AmigaDOS is. > Pauses, lags, and unpredictable response time all contribute toward > making even a fast system seem slow. Apple had a multi-tasking > operating system back in '81. It was called the "Lisa Office System", > and suffered from all of the responsiveness problems I've outlined. > > Amiga fans can help not by explaining why multi-tasking is good, but > by explaining how the Amiga can do multi-tasking without suffering > from the interactive response problems that plague Unix, VMS, and that > plagued the Lisa. I think I just did -- as I just said, the problem isn't the time used by other tasks, but, rather, task switch time. The actual task-switch algorithm may have something to do with it, too, although there's nothing spectacular about the Amiga's besides that it's simple and fairly fast. Unix and VMS both have to swap in a lot of user state and page in their working set (as you mentioned), and I'm not familiar enough with the Lisa to make any comments about it -- unlike certain Macintosh people who are QUITE willing to comment about a machine that they know nothing about :-). But do note that Unix really isn't THAT sluggish, with adequate memory and disk drives -- I can't tell the difference between 1 user (me), at 4am, and 20 users at 9am, on the Pyramid 90x machines at school. With 25 it's slow, with 30, it's nightmarishly slow. Maybe the Unix and VMS machines you are used to are overloaded and/or underequipped? Anyhow, task switch time on the Amiga is a pitifully small amount of time (someone else, with the System Performance Monitor, will have to back me up on this one), and thus by the time your hand is rising from the key, the task has already responded to the keystroke. The only time I've ever seen an Amiga sluggish was when I had 30-40 "dotty windows" going, and started trying to move the windows around and resize them... 10 seconds to put the window in its new location. The actual interaction of grabbing the window and hauling it to where I wanted it was no problem, I guess that the interactive process runs at a higher priority than the process of actually moving the window. Note that "dotty windows" is a CPU-based process that just generates random numbers to randomly place dots inside its window... -- Eric Green elg%usl.CSNET Ollie North for President: {cbosgd,ihnp4}!killer!elg A man we can believe (in). Snail Mail P.O. Box 92191 Lafayette, LA 70509 BBS phone #: 318-984-3854 300/1200 baud
peter@sugar.UUCP (Peter da Silva) (08/23/87)
The UNIX time slice is usually 1/60 of a second (or 1/50 of a second in Europe) for the same reason the Amiga has a 200 line display (and a somewhat larger display in Europe). This is not universal, but it is common. Secondly: VM is always an improvement over swapping, for a given working set and physical memory. The "problem with VM" is that people tend to see it as an infinite memory source and load too much into it. It ain't, and you can't. Thirdly, I do not believe swapping will appear on the Amiga, as Amiga programs are position dependent once loaded. It could be implemented on the Mac. For the Amiga the solution is an MMU... I hope you all remembered where to put MEMF_PUBLIC in your AllocMems, and where to leave it out. Forgetting MEMF_PUBLIC with an MMU will make forgetting MEMF_CHIP when you wanted chip memory positively benign by comparison. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
fry@huma1.HARVARD.EDU (David Fry) (08/23/87)
In article <1372@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >in article <3632@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu (Pierce T. Wetter) says: >> Regardless why do amiga people care about MultiFinder? > >Well see, it's simple. It's because MultiFinder looks so lame compared to the >Amiga Exec, which slices, dices, time-shares, and message-passes, with >complete dynamic memory allocation amongst tasks. And you can bet purty as ya >please that Apple is gonna advertise it as a REAL multi-tasking operating >system, thus pulling the wool over folk's eyes when it comes time to buy a >multi-tasking computer and they found they bought a lemon compared to the >competition. After all, co-processes giving up control to each other do NOT >equal a message-passing multi-tasking kernal... > >In other words, Apple is engaged in a campaign of deception, and those of us >lucky enough to have the real thing, get pretty peeved at their unethical >conduct in doing so... Commodore and Apple are both in business to sell computers, not to make nerdy computer geeks like us happy. I think if you look at sales figures and the over all effect on the industry, you can only say that the Macintosh is "beating" the Amiga. But of course it's not really a competition. As a nerdy computer geek I do envy the multi-tasking of the Amiga. But I have tremendous faith in Apple's ability to see to the heart of a problem and make long lasting, deep solutions. MultiFinder is billed as the first step to a true multi-tasking operating system, and I believe the future steps will be significant. I envy Amiga's multi-tasking, but Amiga owners cannot truthfully say they don't envy the Mac's enormous toolbox that allows for fantastic control and a standardized user interface. They must envy its fonts, its desk accessories, its clipboard, and its large application base. They must envy the seamless (from the user's perspective) interaction between the computer and printers, which has now been extended to the Fax modem. They must envy the fantastically generalized system design which allows the computer to use kanji scripts as easily as Roman, and have kanji appear effortlessly in menus, dialog boxes, everywhere. And starting this month they're going to envy Hypercard. Amiga owners, that's why we like the Macintosh: we have respect for a job well done. The Mac had a lot of problems when it started out, and Apple has taken great strides to get rid of them with elegant solutions. (Anyone who doubts this should read Inside Mac V. 5 to see the rather ingenious steps Apple took to give increased performance *and* compatibility.) Of course we wish would could multi-task now, but we're willing to wait rather than sacrifice the other tangible benefits of our machine, which are much more important in the long run. Real people have real problems and they don't care or know about the technical internals of their computer. You claim that Apple is pulling the wool over people's eyes by claiming multi-tasking. They are only saying what the users will understand; fortunately, the users know so little that it's effectively impossible to fool them on this issue. Could you fool a caveman into believing your Ford was faster than a Ferrari? He wouldn't be able to see a difference between them. When was the last time you saw an ad claiming the Amiga had "a message-passing multi-tasking kernel with dynamic memory allocation among tasks?" David Fry fry@huma1.harvard.EDU Department of Mathematics fry@harvma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
peter@sugar.UUCP (Peter da Silva) (08/23/87)
The real difference is that Tripos is a real-time type O/S, while UNIX is a time-shared one. real-time systems are optimised for fast response time, while timeshared systems are optimised for fair and moderatly fast turnaround for a number of users. Personal computers act more like real-time systems than time-shared ones, so people have come to expect fast real-time response. That's why the Amiga seems so fast. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
richard@gryphon.CTS.COM (Richard Sexton) (08/23/87)
In article <2731@husc6.UUCP> fry@huma1.UUCP (David Fry) writes: > >Commodore and Apple are both in business to sell computers, >not to make nerdy computer geeks like us happy. I think if US Kimasabbee ? Geek for yourself. :-) >cannot truthfully say they don't envy the Mac's enormous >toolbox that allows for fantastic control and a standardized >user interface. Not impressed. Like mine better. Subjective. >They must envy its fonts, We have a program that converts Mac to Amiga fonts. Sure is nice of you Mac folks to put fonts on BBS's throughout the country for us. Thanks again. >its desk >accessories, Got more desk accessories than desk. >its clipboard, Hey! C'mon! We have clipboards. They just dont work, or nobody can figure them out or something. Serious information passing on Amiga takes place through IFF files. We dont pass text, we pass images. >and its large application base. All black and white. :-) (oh yeah, and dithered gray scale) >They must envy the >fantastically generalized system design which allows the >computer to use kanji scripts as easily as Roman, and have kanji >appear effortlessly in menus, dialog boxes, everywhere. This is nice. >And starting this month they're going to envy Hypercard. And according to infoworld, coming for PC's, Ataris, and Amigas. A version for Mike Meyers watch is also planned. >When was the last time you saw an ad claiming >the Amiga had "a message-passing multi-tasking kernel with >dynamic memory allocation among tasks?" Alright you clowns. Who leaked C='s new commercials ? >David Fry fry@huma1.harvard.EDU Yours in 68000'dem, -- Richard Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the key in my ignition..."
lishka@uwslh.UUCP (Christopher Lishka) (08/24/87)
The ONLY thing I envy about the Macintosh (however it is
spelled) is its nifty user interface, which is much easier to use than
any other computer. When it comes to recommending a computer to a
friend, I usually have two choices: Macintosh or Amiga. If my friend
really does not know much about computers but needs one to use (and
has *quite* a bit of money to spend), I recommend the Macintosh,
because it will do more for them in its well-designed user-interface
than the Amiga will. If my friend is a computer-nut but has not yet
heard of the Amiga (an all too often occurence!), I sit them down in
front of one, run some demos (their jaw drops), run some demos at the
same time with multitasking (their jaw drops to the floor), run some
music programs which use the internal sound chips but not midi (their
jaw is now in their lap), run some graphics programs (they now have to
hold their jaw in their hand to keep it from touching the floor), and
then run all of the above at once using multitasking (their jaw clunks
down to the floor). Then, as a dessert, I throw in a game or two
(their heart fails at this point and I need to perform CPR ;-).
Let's face it: the Amiga and Macintosh are two different
machines. One is better in software (both availability and
user-interface): the Macintosh; the other is much further ahead in
hardware (graphics and sound) and some fun OS concepts (multitasking
and message-passing): the Amiga. To me, seeing the light in someones
eyes because he finds he can use a computer in the first place (on a
Macintosh) is just as wonderful as the looks of amazement because a
friend has found a computer which is much better than anything else
on the market for that price (the Amiga).
Now, no flames because I didn't mention anyone elses computer.
By the way, I am thoroughly an Amiga person myself.
-Chris
--
Chris Lishka /lishka@uwslh.uucp
Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu
\{seismo, harvard,topaz,...}!uwvax!uwslh!lishkarap@dana.UUCP (Rob Peck) (08/24/87)
In article <1373@killer.UUCP>, elg@killer.UUCP (Eric Green) writes: > > The only time I've ever seen an Amiga sluggish was when I had 30-40 "dotty > windows" going, and started trying to move the windows around and resize > them... 10 seconds to put the window in its new location. The actual > interaction of grabbing the window and hauling it to where I wanted it was no > problem, I guess that the interactive process runs at a higher priority than > the process of actually moving the window. Note that "dotty windows" is a > CPU-based process that just generates random numbers to randomly place dots > inside its window... > -- > Eric Green Just to be sure nobody gets the wrong idea - it is indeed possible to slow down the machine to a point where you can't really get good performance out of an interactive task. It may come as part of a CPU-hog program (I haven't looked at the source code yet) but I ran into a slowdown that I hadn't expected. I was logged into one of the services and was downloading their message base, in ASCII mode, with no pauses, no "CR for MORE" pause set, as a background task, using ASCII capture mode to RAM: and trying to run MicroEmacs as a foreground task. Amy did not miss a keystroke, but kept them invisible for so long that it made it difficult enough to use I just hadda wait till the download was done. I suspect that the program, COMM 1.34, might possibly be communicating with the serial device in a gimmee-one-character-per-message-passed mode thereby and with characters coming in continuously at 1200 baud it may have kept the system busy enough to keep my microemacs at a lower priority. Though I am an Amiga-fan, I just had to say that if one program is written incorrectly, it can, indeed, hog the system. (By the way, I tried the same program downloading using Xmodem, and did not experience any slowdown). Rob Peck ...ihnp4!hplabs!dsh "SE"S
wilkes@beatnix.UUCP (John Wilkes) (08/26/87)
In article <211@dana.UUCP> rap@dana.UUCP (Rob Peck) writes: /* bulk of article deleted */ >Though I am an Amiga-fan, I just had to say that if one program is >written incorrectly, it can, indeed, hog the system. (By the way, The Amiga does not have exclusive rights to this ``feature''. I remember venerable Tops-20 on a PDP-10 mainframe could drop to its knees because of one poorly behaved user program. I'm certain that other large timesharing systems can suffer similarly. Of course, the ELXSI doesn't have this problem.... infinite number of ;-) (That's a joke, son, a joke.) (But this isn't rec.humor.) (Sometimes I can't tell the difference.) > >Rob Peck ...ihnp4!hplabs!dana!rap John Wilkes --- UUCP: {ucbvax!sun, lll-lcc!lll-tis}!elxsi!wilkes // ARPA: elxsi!wilkes@lll-tis.ARPA // Amiga USPS: ELXSI Ltd., 2334 Lundy Pl., San Jose, CA 95131 \\// lover BELL: (408) 942-0900 "I go on working for the same reason a hen goes on laying eggs." -H. L. Mencken