🚀 go-pugleaf

In article <9602071249.AA22374@dxmint.cern.ch>, Dan Pop
<danpop@mail.cern.ch> wrote:

> nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:
> 
> >So, you can't figure out how to get this to work well on a Mac, eh? 
> >Hmmmm...  <in deep thought for 4.2 seconds>  How about putting a
> >WaitNextEvent() call in one of the inner loops of
> >do_the_computationally_intensive_useful_work();?
> 
> Sounds easy, doesn't it?  Unfortunately, it's a little bit more complicated:
> 
> - If you put it in an inner loop, you risk to spend more cpu time in 
>   WaitNextEvent() than in doing real work.
> 
> - If you put in an outer loop, you risk to have a system with a poor
>   interactive response, once the cpu-bound process has got the cpu.
> 
> - Even if you tune it well on your system, it won't work as well on a
>   slower machine or on the same machine when you restructure the program.
> 
> >I can't wait to see your next completely contrived example that you can't
> >figure out how to solve that the rest of us can trivally solve.
> 
> Trivial solutions are not necessarily good solutions.
> 
> CMT just doesn't cut it well for cpu-bound applications running in
> background, which shouldn't care at all about scheduling issues, which
> aren't their business in the first place.
> 

Dan, You're just all wrong here. I've done what you say is so difficult,
so attend me. I do it in fortran, where I have codes that run in the
background for an hour or more on my PowerMac 6100. In the foreground, I'm
merrily typing, reading email, whatever. Language Systems (now Fortner
research) and Absoft fortran BOTH support automatic inclusion of the code
required to do background processing.

You did raise one good (or at least, new) point:
> - If you put it in an inner loop, you risk to spend more cpu time in 
>   WaitNextEvent() than in doing real work.

LS fortran lets you put in a parameter for a minimum time that must elapse
between times when your code yields time to other applications.
WaitNextEvent does impose a significant overhead if you call it to often,
but if you put in the timer parameter, the overhead imposed  is very low.
I beta test for LSF and when they first came out with the auto-background
feature (about 1989!!) I noticed what you say, I could get the code to
slow down by factors of 2. Putting in a timer parameter of say, 0.1
seconds cuts this to a 5-10% overhead, at most. The elapsed time is still
roughly equal to my reaction time, so I don't notice the "wait" for the
context switch to occur, and my background fortran codes run with no
noticeable degradation in speed. NOTE WELL: All this is done by the
compiler, I never touch the source code.

You should give up on this one; you're wrong. Pick an easier target, like
lack of hardware memory protection!