pbrody@udenva.UUCP (04/13/87)
I had an idea for a small program that would optimize multi-tasking on the Amiga, and I would like to know if such a thing could be done. Idea follows: #define(idea.on) To optimize multi-tasking on the Amiga, set up a program that would detect what window was selected, and to what program it belonged, then the montor program would automatically raise that program's priority to that highest of all the programs running and that way one could multi-task without noticing any slowdown in response time. #define(idea.off) Well, can it be done ? Would anyone like to do it ? ==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-= pbrody@udenva.uucp // // U.S. Mail // // // // 1553 E. Fremont Cir. S. // // Amiga 500 Southglen Co., 80122 // // Amiga 1000 \\ \\// // Amiga 2000 The above opinions are purely my own \\ // // and no those of the University of Denver \//\// --=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-
hadeishi@husc7.UUCP (04/13/87)
Re: Optimizing multi-tasking . . . "Optimizing" multi-tasking by raising the current input-active program to the highest priority would NOT optimize multi-tasking at all, but would turn the Amiga into a single-tasking machine a la Switcher. ONLY one task could then run at a time, the currently active one. The Amiga is ALREADY "optimized for multi-tasking" in that tasks which are waiting for input get NO CPU time. A task that wants to run and isn't waiting for input expects and deserves some CPU time (i.e., a compiler.) Of course, if you wanted to turn your beautiful multi-tasking machine into a Macintosh, you could certainly write this program. -Mitsu
dillon@CORY.BERKELEY.EDU.UUCP (04/14/87)
> "Optimizing" multi-tasking by raising the current input-active >program to the highest priority would NOT optimize multi-tasking at all, >but would turn the Amiga into a single-tasking machine a la Switcher. >ONLY one task could then run at a time, the currently active one. I think the idea was "I have several things running at once, but would like my Amiga to pay more attention to the application who's window I'm currently typing in (e.g. active window)" Assumming this is some kind of editor or something (that's waiting most of the time), you could simply raise its priority to, say, 2. You certainly do not want to raise its priority above any system tasks as you can get into lockout situations in some cases. That way, you can still have 10 dotty windows going in the background and your editor *looks* like it's going full speed (At the cost of the dotty windows), etc.... I myself have never encountered a situation where I'd actually need a utility like this. On say, a VAX785 with a load of 14 and 60 users, perhaps, but on my lowly Amiga??? at most I have only one or two programs that are CPU hogs, and although this makes a noticable impression when I type in my editor, it doesn't slow it down so much to make me want to do something so drastic. -Matt
jesup@steinmetz.UUCP (04/14/87)
In article <1657@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes: > "Optimizing" multi-tasking by raising the current input-active >program to the highest priority would NOT optimize multi-tasking at all, >but would turn the Amiga into a single-tasking machine a la Switcher. >ONLY one task could then run at a time, the currently active one. ... > -Mitsu Sorry, but that is not what he meant. What he wants (At least I think so) is a classic scheduling strategy for multitasking systems to give good response time, while still allowing background tasks to run. What you do is up the priority of any task that gets USER input, temporarily. So when the user clicks the mouse, or types a letter (or line), his tasks gets a nice fat slice of time for, lets say, half a second, and then it drops back down to normal. This produces greatly improved response time when CPU-bound tasks are running in the background, without producing a dramatic slowdown (or stoppage) of the background task. Even what he actually said (raise it until you give input to another task), isn't what you took it as, backgound tasks would still run if the forground task ever Wait()ed, or otherwise blocked. Randell Jesup jesup@steinmetz.uucp jesup@ge-crd.arpa
daveh@cbmvax.UUCP (04/15/87)
in article <3454@udenva.UUCP>, pbrody@udenva.UUCP (Paul Brody ) says: > To optimize multi-tasking on the Amiga, set up a program that would detect > what window was selected, and to what program it belonged, then the montor > program would automatically raise that program's priority to that highest of > all the programs running and that way one could multi-task without noticing > any slowdown in response time. Well, I'm sure it could probably be done. I also know that I, for one, do not at all want this feature inforced on me, at the very least. This is probably a personal preferences item, like the idea of automatically selecting windows when they're pointed to. I often run compilations or other rather CPU intensive applications in the "background" (i.e. the window that's not selected), while I run Wait() intensive applications, like text editors, in the "foreground" (i.e., the selected window). I'm more than willing to give up an occasional slowdown in typeahead (very occasional has been my experience) in return for a faster compilation. On the other hand, if you're running several CPU intensive applications at once, you may find it an advantage to have the current window be at the highest priority automatically; much easier than doing a SetTaskPri or whatever every time you change windows. Perhaps a tightly coded background task that looks at the currently defined top screen/window (of course remembering the previous) and bumps up the priority of the task associated with the currently selected window would do what you want. I've no need for it, but like the Sun-Alike program (forget the name, I tried it once, but I'm used to Amiga window priorities), it should be possible to write it given the appropriate desire. > pbrody@udenva.uucp -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" BIX : hazy "That's all she wrote" -J. Strapp
keithd@cadovax.UUCP (04/17/87)
In article <8704140116.AA01418@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: on 'optimizing' multi-tasking: > That way, you can still have 10 dotty windows going in the background >and your editor *looks* like it's going full speed (At the cost of the dotty >windows), etc.... I would think anyone who wastes his time running 10 dotty windows in background while running an edit session in foreground deserves whatever lousy response he gets. I for one, can't complain too much about multi-tasking optimization, I've quite often done xmodem or kermit downloads and done other operations at the same time with only slightly noticeable degradation in performance. As far as I was concerned, the transfer was the most important task, and the one I would want to optimize (as a background program) if I wanted to do that anyway. > at most I have only one or two programs >that are CPU hogs, and although this makes a noticable impression when I >type in my editor, it doesn't slow it down so much to make me want to do >something so drastic. > -Matt Ditto. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
dillon@CORY.BERKELEY.EDU.UUCP (04/18/87)
I wrote: >> That way, you can still have 10 dotty windows going in the background >>and your editor *looks* like it's going full speed (At the cost of the dotty >>windows), etc.... > somebody else: >I would think anyone who wastes his time running 10 dotty windows in background >while running an edit session in foreground deserves whatever lousy response >he gets. Your remark is totally uncalled for! It should be obvious to any half-baked idiot that the inclusion of "10 dotty windows" in my example was simply to exemplify the point I was trying to get across. The inference is that when you have many other CPU bound tasks running, you would still be able to use your 'primary' application without a noticable slowdown. I also clearly stated that I have yet to find the need for such a feature. -Matt