rjc@geech.ai.mit.edu (Ray Cromwell) (01/23/91)
It seems a few people misread my original message about preemptive vs
cooperative multitasking and my chart. Re-read my message. I said
that my chart assumes each task uses ALL of its timeslice, this means
no waiting is occuring. Mac multitasking will become jerky and bogged
down before Amiga tasks will in a heavily loaded system. Consider the
following psuedo-code.
Mac:
GetNextEvent();
HandleTheEvent();
while(condition) {
do compute intensive loop
such as uncrunch, fractal, trace, search a buffer, fibonacci,etc
}
Amiga:
CheckMsgPort();
HandleTheMsg();
while(condition) {
compute loop
}
Now run 3 or 4 copies of this program on each machine. On the Mac,
the loop will grab 100% of CPU time and the other 3 copies will be DEAD.
On the Amiga, all 4 will run but at a slower speed (assuming equal priority).
The Mac programmer must decide CAREFULLY where to place I/O calls to
give up the CPU. If the compute loop is sufficiently complex( nested),
he will have to put them in many places.
One can readily test this on the Amiga by starting up 2 or 3 copies of
MandelVroom or BioMorph. I did it, and on my 7mhz Amiga, the fractal
slows down linearly, but it does NOT become jerky. On the Mac, the other
fractal geneators will become jerky(possibly dead).
Mac users must consider what Amiga users typically do. An artist may
place a long ray-trace task at -1 priority in the background and let it
run for a week! A programmer will put a compile in the background while
editing or reviewing source.
I suspect the Mac's lack of priorities and preemptive tasking would cause
foreground tasks to become jerky if compute intensive tasks are placed in
the background (such as a long ray-trace).
Also, I made the comment 'I don't consider the Mac to be multitasking
since ithasn't been multitasking since the start.' Let me clarify this.
On the Amiga, programming rules about multitasking have been around
since day one. However, on the Mac, I suspect the vast quantities of
software published before Multifinder was invented will be CPU hogs.
The Amiga faces the same problem with device independent graphics.
Most Amiga programs assume bitplaned graphics and alot of them write
directly to display memory. It will be hard for the Amiga to become device
independent and still work with older programs. The MS-DOS world has
an even bigger problem. No matter how many kludges IBM companies come up
with, they will always have to contend with MS-DOS and 8088 compatibility.
If they don't, they have to break millions of dollars of software out
there.
Now look at the Mac. Apple is attempting to layer a multitasking
interface ontop of a non-multitasking core. This is almost the same
as layering MS Windows ontop of MS-DOS. As far as I know, the Mac
has none of the facilities the Amiga has for sharing interupts,
exceptions, handlers devices, console windows, keyboard strokes.
Consider the Amiga's Task Control Block, or struct Process, can anybody
tell me what the Mac equivelent is?
--
Destroy Iraq, send them the Mac!passaret@copernicus.crd.ge.com ("Mr. Mike" Passaretti) (01/23/91)
OK, I'm going to throw an example up in the air.
A couple of days ago, I wanted to load into Excel the "Files"
lists from several ftp sites. The intent was to sort and
prioritize for some batch mode ftp-ing late at night. So I
ftp the stuff over to my Plus (NCSA Telnet. It crashes a LOT,
but when it works, it's great). I go into Excel and open the
text file. Great. So I do a test "Parse" on the first line to
break it up into fields. It looks OK, so I select the whole
file (Several thousand lines) and do a "Parse". I then go over
to the apple menu to move back to telnet to get some useful work
done. No go. OK, try Master Juggler. No go. Excel wants all
of it. Go get a soda. Still cranking. 20 minutes later, it's
finally done, and I can get some work done. This would NOT have
happened on my Amiga. End of example. For those who will, no doubt,
tell me I have a broken System, Finder, Excel, etc. I don't CARE.
The bottom line is that I couldn't do useful work with what I've
got, and most productivity software on the Amiga is at least well
enough behaved that that is not a problem. No matter how old it
is. Hell, even my attempt at porting 'sc' does better than that.
My local Apple dude tells me "Wait for System 7.0". Yeah. right.
on a 2.5 MB Plus. I hope my IIci comes in soon.
- MM
--
passaretti@crd.ge.com {whatever}!crdgw1!brahe!passarettorrie@cs.stanford.edu (Evan J Torrie) (01/24/91)
rjc@geech.ai.mit.edu (Ray Cromwell) writes: > The Mac programmer must decide CAREFULLY where to place I/O calls to >give up the CPU. If the compute loop is sufficiently complex( nested), >he will have to put them in many places. Yes. This is the failing of the Mac multitasking system. You HAVE to be a clever programmer to decide where to give up control. On the Amiga, it doesn't matter how bad a programmer you are, the OS will come to your rescue... :-) > I suspect the Mac's lack of priorities and preemptive tasking would cause >foreground tasks to become jerky if compute intensive tasks are placed in >the background (such as a long ray-trace). Only if the compute intensive task doesn't yield the CPU often enough... With the commercial ray-tracer I use on the Mac, I notice a slowing down in the word processor on top, but it doesn't get jerky. >On the Amiga, programming rules about multitasking have been around >since day one. However, on the Mac, I suspect the vast quantities of >software published before Multifinder was invented will be CPU hogs. Yes. Luckily, there are few programs published before MultiFinder which haven't had an update since the advent of MultiFinder. [Actually, this is an interesting computer history lesson. Get out your copy of Mac/AmigaWorld from four years ago. Go through all the advertisements and see how many of those programs are still in existence today in the same state as they were four years ago.... probably not very many] >The Amiga faces the same problem with device independent graphics. >Most Amiga programs assume bitplaned graphics and alot of them write >directly to display memory. It will be hard for the Amiga to become device >independent and still work with older programs. Even Amigaoids will agree that this is one area where Apple has an advantage. >The MS-DOS world has >an even bigger problem. No matter how many kludges IBM companies come up >with, they will always have to contend with MS-DOS and 8088 compatibility. >If they don't, they have to break millions of dollars of software out >there. Eventually, though, the old software becomes obsolescent... the time it takes for this to happen depends on the size of your installed base. For example, Apple essentially no longer supports 64K ROM machines... eventually they will start phasing out support for non 1.44MB floppy disk machines [perhaps even as soon as System 7.0, which won't fit on 800K disks]. Most IBM software now assumes an 80286 at least. Perhaps by the time they get out to 32-bit Windows and an assumed 80386, they will start to drop off support for the segmented memory model of the 8088/286. I see this happening sometime around the year 2010 :-) > Now look at the Mac. Apple is attempting to layer a multitasking >interface ontop of a non-multitasking core. Luckily, I think Apple will give up on this, and either rewrite the Mac OS from the bottom up, or just migrate everybody to a variant of A/UX. >This is almost the same >as layering MS Windows ontop of MS-DOS. As far as I know, the Mac >has none of the facilities the Amiga has for sharing interupts, >exceptions, handlers devices, console windows, keyboard strokes. >Consider the Amiga's Task Control Block, or struct Process, can anybody >tell me what the Mac equivelent is? Apple's Process Manager (which was internal knowledge only in System 6.0), will be an integral part of System 7.0, and calls to spin off processes etc will be available (according to a talk I went to at MacWorld). -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/24/91)
In article <15992@crdgw1.crd.ge.com> <passaretti@crd.ge.com> writes: >The bottom line is that I couldn't do useful work with what I've >got, and most productivity software on the Amiga is at least well >enough behaved that that is not a problem. No matter how old it >is. Hell, even my attempt at porting 'sc' does better than that. >My local Apple dude tells me "Wait for System 7.0". Yeah. right. >on a 2.5 MB Plus. I hope my IIci comes in soon. OK, I'll buy your conclusion, but did you HAVE to use Microsoft "we don't care what Apple's programming guidelines are and we'll roll our own interface" Excel? I mean, most versions of Excel couldn't deliver the full capabilites of the System (one version required being run in the first meg, then only _part_ of the program had to be). Maybe y'all shouldn't be so hot to get one of the big companies to do bizness apps for the Amiga. "Sure, we'll do Word for your platform." "Hey, look at that; they gave us a way to turn off Multitasking. Bet we could make this program really hum."
lsr@Apple.com (Larry Rosenstein) (01/24/91)
In article <12916@life.ai.mit.edu>, rjc@geech.ai.mit.edu (Ray Cromwell) writes: > > The Mac programmer must decide CAREFULLY where to place I/O calls to > give up the CPU. If the compute loop is sufficiently complex( nested), > he will have to put them in many places. You definitely have to insert extra calls, but it isn't as hard as you make it out to be. There are 2 approaches you can take: (1) You run performance tools to find out where the program spends most of its time. (2) You mechanically insert calls into all the loops of the program, and at the beginning and end of each routine. (The latter can be done automatically by some of the Mac compilers.) These calls are to a routine that yields the CPU every N ticks. I've used each of these techniques to port vanilla C programs to the Mac and get them to run in the background. > Mac users must consider what Amiga users typically do. An artist may > place a long ray-trace task at -1 priority in the background and let it > run for a week! A programmer will put a compile in the background while > editing or reviewing source. And Mac users do exactly the same things. I put compiles in the background all the time, and I suspect that most if not all rendering programs also work in the background. > I suspect the Mac's lack of priorities and preemptive tasking would cause > foreground tasks to become jerky if compute intensive tasks are placed in > the background (such as a long ray-trace). The foreground task sometimes pauses (primarily during I/O) but mostly everything runs smoothly. > software published before Multifinder was invented will be CPU hogs. This is true of CPU-bound programs. Programs that are user-input-bound are not CPU hogs under MultiFinder. > Consider the Amiga's Task Control Block, or struct Process, can anybody > tell me what the Mac equivelent is? These things exists in the internals of MultiFinder, but they up to now they have not been exported to programmers. This is changed in System 7.
davewt@NCoast.ORG (David Wright) (01/24/91)
In article <11834@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >You definitely have to insert extra calls, but it isn't as hard as you >make it out to be. There are 2 approaches you can take: It isn't a matter of being HARD, it's a matter of EFFICIENCY. By inserting extra calls you: a) Make every program that behaves bigger b) Waste part of the programs time slice to do something that the OS should be doing for it in the first place. >I've used each of these techniques to port vanilla C programs to the Mac >and get them to run in the background. Gee, and all I have to do is compile them. >And Mac users do exactly the same things. I put compiles in the background >all the time, and I suspect that most if not all rendering programs also >work in the background. Of course they work, but they all run at the same priority. If you put a compile in the background, your foreground task is going to slow down, whether you want it to or not. >The foreground task sometimes pauses (primarily during I/O) but mostly >everything runs smoothly. What happens if you try to do a download at 9600 baud on a heavily loaded system? Wouldn't it be nice to be able to set the download task at a higher priority? >This is true of CPU-bound programs. Programs that are user-input-bound >are not CPU hogs under MultiFinder. And neither are they on the Amiga. But on the Amiga even CPU-bound programs won't be CPU hogs unless you intentionally want them to be. >These things exists in the internals of MultiFinder, but they up to now they >have not been exported to programmers. This is changed in System 7. Ah, so you are JUST NOW releasing info that programmer should have had all along. And I suppose you expect programmers to drop their old techniques overnight and start using the "correct" ones? Dave
swalton@solaria.csun.edu (Stephen Walton) (01/25/91)
In article <11834@goofy.Apple.COM>, lsr@Apple (Larry Rosenstein) writes: >You definitely have to insert extra calls, but it isn't as hard as you >make it out to be. There are 2 approaches you can take:... > >I've used each of these techniques to port vanilla C programs to the Mac >and get them to run in the background. On the Amiga, to get vanilla C programs to run in the background, you do: 1>cc program.c 1>ln program.o -lc 1>run program Steve