🚀 go-pugleaf

mlelstv@serpens.rhein.de (Michael van Elst) writes:
>jasonb@cs.uwa.edu.au (Jason S Birch) writes:

>That's the key. CPU intensive stuff is _not_ lower. You don't want
>to manually change the priorities and you do not want every program
>to change its own priorities.

You *do* want to manually change priorities if the long-running CPU
intensive process is going to affect interactive performance
needlessly. This applies to text editors, shells, *anything* -- not
just MUI programs. You run a few CPU intensive processes at priority
0, then try typing into your text editor. Unless your A3000 is a lot
faster than my A4000, it will become sluggish. Now run them at -1.
Your text editor responds as if they weren't there, and they don't
actually get *less* CPU in the long term because of it -- the text
editor simply gets the cycles it would have had anyway, except it gets
them immediately it wants them.

I seem to recall that Exec's absolute scheduling based soley on
priorities has long been an advantage boasted about by Amiga advocates
-- lower the priority of the CPU hog and it only gets cycles that
would have gone unused anyway, keeping the machine responsive, unlike
Unix or NT. It's hardly going to be much of an advantage if we're all
too afraid to move anything below 0, now, is it?

>The default priority of a process is zero.

Yes. And for a long time now, we've been able to modify it.
ChangeTaskPri and just about every monitor ever written for the Amiga
allows you to change priorities. It's there for a reason.

>So provide timely feedback as AmigaOS did it all the time: by using
>input.device. It exists, it is the standard, it works well, you don't
>need a scheduler that outguesses a programs intention.

It also means that every class of MUI would be running at pri 20 by
default unless the programmer explicitely did otherwise. Which would
you prefer: MUI apps running the bulk of their code at pri 20 because
the programmer didn't know any better, or MUI apps running the bulk of
their code at pri 0? Which is more friendly to the rest of the system?
In one case, you basically kill every other app on the computer if the
programmer messes up. In the other, the particular app isn't very
responsive if the programmer messes up. I know which I'd prefer.

The AmigaGuide datatype is a good example of what can happen when you
adopt the former scheme. I believe ClassAct also does this, but makes
it easy for the programmer to put parts of the custom class on the
application's context if they feel it would take too long.

>>Another one is wanting to have a uniform notification scheme which can
>>work uniformly on any attribute of any object. Running your GUI event
>>handling code on two separate tasks, one at pri 20 and one at the usual
>>pri, would make this very messy.

>This isn't more difficult than other code that needs several tasks.

It is if you want to keep notification working on everything and you
don't want the programmer to have to deal with the internals of your
OO system (BOOPSI).

>And if you use MUI you have to do the same. Wether your code spawns
>that process or you use the existing input.device process.

No -- because the OO system *itself* doesn't run at different
priorities. Within a custom class, the OO mechanism is still running on
the same context as the rest of the classes. Any method you call, any
attribute you set, is all still on the same context. Internal functions
to your class can be running on different contexts, but that has
nothing to do with your OO mechanism. Within those other contexts, you
can't call methods and set attributes of other objects directly. It
would get very messy to implement if you could, and you would need to
implement it that way if you didn't want the whole thing running at
pri 20 by default.

>>So MUI does it all on the usual
>>priority task's context, which makes MUI simpler but means the
>>programmer has to be aware of the issues of GUI responsiveness and
>>ensure his event handling loop is always ready and waiting.

>Which is more difficult and interferes with more programs than simple
>semaphore locking of data structures.

Why is it more difficult? The subtasks are completely under your
control, and aren't interacting with the other tasks in unknown ways
because they only interact through *your* mechanisms, when you've
explicitely asked them to.

>>You even have some things -- like the
>>AmigaGuide datatype laying out AmigaGuide documents -- running at pri
>>20 when they really shouldn't be.

>Sure. I never said that existing BOOPSI gadgets are perfect but
>datatypes already provide a method to offload expensive operations.
>This is a function of the datatypes.library.

That's right -- the *programmer* is left the task of offloading
expensive operations, with disasterous results if they don't. The
worst that happens with MUI is individual applications that feel
sluggish. A complex AmigaGuide document can stop my mouse pointer
moving for a second or more.

>>Or, to put it another way -- you can lower the priority of tasks not
>>directly communicating with the user.

>Again. That is something YOU have to do.

And something I always did, even before MUI and Executive came along.
Applications running CPU intensive tasks at pri 0 have always been
annoying, because they make the system sluggish -- but at least we've
always been able to move them if necessary.

>Think about programs that do not do event handling. Something simple
>as a compiler or anything written in straight ANSI C.

If they take long enough for you to want to do something else
interactive in the meantime, think about using ChangeTaskPri, or Scout,
or ARTM. Or use Executive, and let it happen automatically.

>>>With the standard Exec scheduler you can even allow it to run on
>>>the same priority. 

>>But what do you gain from doing so?

>You do not need to write special code to keep MUI and Executive happy.
>That's what it is.

Again. Sigh... This has nothing to do with MUI and Executive. Running
CPU intensive processes at pri 0 *will* make the machine feel slower.
You *will* notice the effect in your text editor. You *will* notice
that, while a button still depresses instantly, the application takes
longer to respond. Take advantage of the Amiga's multitasking and run
a raytracer, AWeb, and a text editor all at pri 0, and you will start
becoming frustrated while the other guy who's put the CPU intensive,
non-interactive stuff at a lower priority doesn't even notice
anything's happening, *at no real detriment to the CPU intensive
tasks*!

>>Of course they don't. I'm not talking about changing AWeb so it won't
>>"interfere" with MUI --

>Run a MUI program. Run another CPU-intensive program at the same
>priority (i.e. 0: the default priority). Watch the MUI program to
>become sluggish (if it isn't already).

Watch your text editor also become sluggish. Watch the computer become
slow to respond to user input. Sure, the GadTools buttons may depress
instantly, but it will be slower to respond and you'll notice this.
Listviews will be slow to scroll. All of this is unnecessary, because
it would all disappear if only the CPU intensive program was running
at a lower priority.

I just did a simple test. I did an 'ls -l' of SD0:, which has four files
in it. It took 0.5 seconds. I then ran two CPU intensive processes at
the same priority. Just two. It took 4.0 seconds. Eight times longer.
Why? Well, because the ls was doing I/O -- it kept waiting, voluntarily
giving up the CPU before its quantum (4 VBLs) was up. Once it had
given up the CPU, it didn't get it again until the two CPU intensive
tasks had completely used their quantums, even though the packet it was
waiting for had arrived -- it was at the same priority, so the other
two tasks weren't pre-empted. So, it eventually gets the packet, and
Wait()s for the next -- oops, there goes the CPU again. If it's only
using, say, 1/4 of its timeslice before it waits again, it could easily
be getting just 1/9th the CPU even though just three tasks are trying
to use it. Giving up the CPU before your timeslice is up doesn't mean
you can "save it up" for next time around, you lose it forever. This is
why running interactive tasks at the same priority as CPU intensive
tasks is such a bad idea, and can make them feel so drastically slower.
Note that if the ls was running at just one level above the other two
tasks, then as soon as the packet it was waiting for arrived, it would
process it. The other two tasks would still get the CPU whenever the ls
waited (which is quite often the case with tasks doing I/O, or
interactive tasks).

>>I'm talking about making AWeb *itself* more
>>responsive,

>AWeb is responsive. If you run Executive at the same time it isn't.

It isn't responsive if (gasp) I run another CPU intensive task at
priority 0, or if it's coping with many connections and image
decompressions while I'm trying to scroll through a large document.
If the CPU intensive tasks it spawns ran at a lower priority, it would
be. (This is without running Executive, BTW.)

>>In case it isn't obvious -- in order for a MUI program to remain
>>responsive, all that's required is that no CPU intensive tasks be
>>competing with it for the CPU at the same priority.

>So none of the standard programs is allowed to run, because these
>programs surely do not change task priorities to keep MUI happy.

Many programs (eg. Real3D, IBrowse) spawn subtasks to do CPU intensive
tasks. (Note that *only* CPU intensive programs need do this, other
"standard programs" make no difference.) Some even allow the user to
set their priorities within the program (eg. IBrowse). Those that don't
can be manually set by the user, or automatically changed by Executive.
This is *not* just about "keeping MUI happy", much as you would like it
to be so. This is about making an 'ls' finish as fast as it could.
About your text editor responding to your typing, or scrolling your
document, when you want it to. Your CPU intensive task doesn't suffer
from being at a low priority, but your interactive tasks sure as hell
do if it isn't.

>>Of course it doesn't. Over a long period of time they get the same
>>amount of CPU (all else being equal), but in one second they can get
>>vastly different amounts.

>Which means that it is pretty unusuable.

Of course not. I don't care if two Real3D drawtasks are exchanging the
CPU every second or every 1/50th of a second. It makes no difference
to the actual completion time (actually, the longer quantums might
actually make it faster because eg. the cache remains useful for
longer). All I care is that they're running at a lower priority than
my editor and anything else interactive I want to do -- otherwise,
like the 'ls' example above, the interactive stuff gets *very* slow.

>>get one seconds' worth of CPU, but they would've got it in bursts of
>>about 0.05 seconds at a time.

>And that's what we want to create the illusion of concurrency:
>multitasking.

"CPU intensive" generally refers to things that take many seconds and
use the CPU for their entire quantum. Tasks which are interactive will
have a higher priority, will give up the CPU often, and will still
appear to be running concurrently. Higher priority tasks, which under
Executive are usually those that are event-driven or I/O bound, still
pre-empt those CPU intensive ones. Tasks which are currently receiving
focus from the user will also be raised even higher, to ensure they
are responsive. Any special cases which don't fit into the above
categories can be explicitely catered for in the preferences.

Executive doesn't do *anything* that a user couldn't do (if they were
fast enough). It doesn't change Exec's scheduler, it doesn't make
AmigaOS non-pre-emptive. It doesn't even change priorities, if you
don't want it to.

>>I would make an entry for them in Executive's preferences.

>So another thing the user has to change to keep Executive happy.

Executive couldn't care less. It's to keep the user happy. Are you
happy waiting 4 seconds for an 'ls' that *could* have been finished in
0.5? Just because *two* other tasks are running?

>>As I said, nothing I've said has anything to do with "making MUI
>>happy".

>Sure. To make MUI happy you have to run CPU intensive processes
>at priorities below 0.

And your editor, and your shell, and your C compiler (typically lots of
I/O), and the listviews of your GadTools programs... Just saying MUI is
the only one affected over and over doesn't make it any more true. And
again, MUI couldn't give a damn. It's the user I'm thinking of.

>>Given he's already spawned off network transferring and image decoding
>>onto subtasks, is it really such a terrible thing to want page layout
>>there as well?

>If page layout is fast enough there is no need for just another task.

157 seconds for one page (the 600K page I was referring to earlier,
showing our site's usage statistics which I check now and then) is
quite a long time, so I suppose you're agreeing now that there *is* a
need for just another task? Or perhaps you think we should only ever
look at small pages so the delay doesn't get too long? Sounds like a
real good, all-purpose solution.

If I click "<-", it still takes 18 seconds before the (small) previous
page is shown again, and 119 seconds before the big page is displayed
again if I then click "->", and I *can't* stop it if I change my mind.
(Interesting tidbit -- IBrowse completely displays the same page in 107
seconds, including all transferring; AWeb takes 119 seconds just to
display it from the cache, and it's not even using the disk to store
it.) I have to wait for it to finish (again, this is without
Executive), and it doesn't even display the HTML progressively when
using "<-" or "->" like it does while transferring the data across the
network. Also, presumeably his page layout code -- since it is also
doing event handling when loading it across the network the first time,
which still works albeit sluggishly -- must keep stopping to process
events. If it was in a separate task it should actually be *easier*,
because it separates the code into two distinct types.

BTW, I've solved the problems it was having with Executive (not
processing input at all while loading the page) by making an entry for
it in the preferences. I'd still like a separate task, though, so I
can prioritize them rather than making AWeb become sluggish under a
heavy load (which IBrowse doesn't).

>Anyway, this is not a problem unless Executive tries to outguess the
>programs.

Hmm... Just about every point I've made about why wanting the CPU
intensive code running on a separate thread at a lower priority than
the main event-handling task is completely independent of both 
Executive and MUI, yet all you ever do is blame Executive and MUI. It
has nothing to do with them! In fact, Executive partially alleviates
the problem, because using it I can at least set AWeb and all its
child tasks at a low priority so they won't make the rest of the apps
(like my text editor) sluggish when doing a lot of work, just like
*any* CPU intensive process running at priority 0 will do. *You* might
be happy merely having buttons depress instantly, but *I* want the
computer to respond to my actions instantly when it can, and running a
CPU intensive process at a low priority enables that.

>>Well, even before I ran Executive, I always set priorities manually to
>>ensure processes like my editor ran higher than processes like Real3D.

>If you work in a shell, do you set the priorities for every command
>you start ?

It depends on how long it's going to take. If I'm going to be waiting
at the prompt for it to return, no, there'd be no point. If it was a C
compile that was going to take 20 minutes with the optimizer, of course
I would. Same with Real3D -- doing edit-compile-run cycles with a
week-long raytrace running in the background at the same priority is no
fun. Run it at a lower priority and you don't even know it's there.
This has long been one of the strengths of the Amiga.

>                                Michael van Elst
>Internet: mlelstv@serpens.rhein.de

-- 
Jason S Birch                        ,-_|\ email: jasonb@cs.uwa.edu.au
Department of Computer Science      /     \ Tel (work): +61 9 380 1840
The University of Western Australia *_.-._/ Fax (work): +61 9 380 1089
Nedlands  W. Australia  6907             v  Tel (home): +61 9 386 8630