🚀 go-pugleaf

In article <4aeof0$v8t@quandong.itd.adelaide.edu.au>,
Paul Joswig <joswig@achilles.cs.adelaide.edu.au> wrote:
>I haven't yet used any compilers under OS/2 except gcc/emx.  I wrote a
>program to help solve a puzzle in a game, invloving moving some
>bishops on a chess like board.  Anyway, it was a CPU intensive program
>that ran for say 30 seconds on my machine.  Now, the weird thing is
>this...  normally I find that when I move focus away from a running
>program that it's priority drops and hence it slows a little; well, at
>least if something else is running at the same time.  Now, with my
>program running in a window, it ran MUCH faster when I moved the focus
>from the window.  I mean the output scrolled at least twice as fast.
>Also, the WPS shell became unusable because, I assume, the program was
>stealing all the CPU.  This was weird!  Can anyone enlighten me?

A program running in normal priority class will get a priority boost
whenever there is I/O - like keyboard/disk - and probably mouse.

But the point is, if your program is the only thing running (everything
else will be idle most of the time), then you will not notice the priority
boost.  It is only when you have a CPU bound program running in the
background, and for instance a text editor in the foreground.  Whenever
you move the cursor keys, the text editor will quickly respond to the I/O
and move the cursor.  This is because it gets a priority boost and will
preempt the background program - rather than waiting for its next time-slice.

You can use a program called Watchcat to watch the CPU that is being used
by each program, and even look at the priority/status of each thread.  Using
this, you can see the priority change when the priority boost occurs.

As for the WPS being unusable, I am not sure about this.  The WPS has many
threads, with lots of those running at a fixed high priority.  So in that
case they will always preempt any CPU bound normal priority program (it
is the user interface).  But you can be silly and set your priority to be
above the WPS/PM - it is not a wise thing to do for a CPU bound program.

For a program running in a window though, remember you will have your program
thread taking lots of CPU, but if there is scrolling or other video update
then that will also take (lots of) CPU.

As for some emx/gcc feature - I don't know - maybe Watchcat may help.  You
could always run your program at idle priority.

Good Luck - Mark

-- 
| // Mark Stead  -  Internet: Work mark@unico.com.au	      |
| // "Save Ferris!"	      Home mark@daemon.apana.org.au   |
| // There is always one more bug!                            |
| // Windows 95 : Busy or Unstable?  Don't ask me, I run OS/2 |

In <4aeof0$v8t@quandong.itd.adelaide.edu.au>, joswig@achilles.cs.adelaide.edu.au (Paul Joswig) writes:
>I haven't yet used any compilers under OS/2 except gcc/emx.  I wrote a
>program to help solve a puzzle in a game, invloving moving some
>bishops on a chess like board.  Anyway, it was a CPU intensive program
>that ran for say 30 seconds on my machine.  Now, the weird thing is
>this...  normally I find that when I move focus away from a running
>program that it's priority drops and hence it slows a little; well, at
>least if something else is running at the same time.  Now, with my
>program running in a window, it ran MUCH faster when I moved the focus
>from the window.  I mean the output scrolled at least twice as fast.
>Also, the WPS shell became unusable because, I assume, the program was
>stealing all the CPU.  This was weird!  Can anyone enlighten me?

This could be whats happening. (?)

OS/2 definitly slows foreground tasks right down when you
move to another task however, except repaints of windows
are deemed to be lower in priority than the running of the 
program. The result is that the program might be running
fast, but the updating of the display happens at a more
leisurely rate (a different concept than windows which
slows everything down, so that it can "appear" fast)

If a window is partially covered, then the updating or
repainting can happen faster, so the program looks like
it is working faster, even if it's not.

This is particularly apparent where you run 256color
display, as there is a lot of graphics work to do.

Regards

David Lyon
Hotwire Business Systems