🚀 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.
] 

Err... translate following pseudocode to language of choice:

global integer  gNextCheck;

procedure DoMultiTask(integer sleepTime,slice)
begin
   EventRecord   myEvent;

   if (TickCount() > gNextCheck) then
      begin
      if (WaitNextEvent( everyEvent, &myEvent, sleepTime, NULL ) then
         begin
         //put optional event handling here or leave empty.
         //most might at least put a spincursor call.  :-)
         end
      gNextCheck = TickCount() + slice;
      end
end

sleepTime = time in 1/60th sec you are willing to surrender cpu context for.
            Suggested values: 1 - 6.  Larger is more multiuser friendly.
slice     = time period you want to keep the processor before surrendering it.
            Suggested values: 1 - 6.  Smaller is more multiuser friendly.


Create this procedure in a library or anywhere you want, then call it
frequently in your code with just:

DoMultiTask(1,1).

This will automatically throttle itself to not relinquish the cpu too much
so go ahead an put it in all by the shortest inner loops, and even then it
probably won't hurt you.  The overhead for the if(TickCount()... call is
extremely tiny - it is just a handful of assembler instructions and
consumes just a handful of clock cycles - further, dynamic branch
prediction will tend to make it NOT take any real cpu time (since the vast
majority of the time this test will fail).

To make it even more efficient, if your compiler supports it, inline the
procedure call which will remove the jmp necessary to reach the tickcount
check.

] Trivial solutions are not necessarily good solutions.
] 

If you don't think the solution I just posted above is trivial, then I'm
sorry, there is not much more we can do for you.

Cheers,

Dr. Mel Martinez
The Johns Hopkins University
Dept. of Physics
mem@jhu.edu