visualpython-users

RE: [Visualpython-users] nested frames, cpu times

[Kuzminski, S. R <SKu...@fa...>]

Hmm, Stonehenge takes ~20% of the cpu on my XP laptop. The date at the
top of __init__.py is "Visual-2003-10-05".  Perhaps I will try a more
recent release.

If that renderer thread doesn't sleep at some point in its loop, it will
consume a lot of CPU just looping, but usually that behavior is to use
100% of the CPU.

thanks,
S

-----Original Message-----
From: Bruce Sherwood [mailto:Bru...@nc...]=20
Sent: Wednesday, May 12, 2004 5:11 PM
To: Kuzminski, Stefan R
Cc: vis...@li...
Subject: Re: [Visualpython-users] nested frames, cpu times

That's odd. I ran lathe.py from the VPython demo suite and observed CPU=20
usage, which was less than 1% on a 2.6 GHz Windows XP machine. Note that

lathe.py makes a display and then ends. Even running stonehenge.py,=20
which has a continuous animation and looks for user mouse inputs, runs=20
at less that 1%. There is a rendering thread which many times per second

renders the scene, and it isn't "smart" -- it doesn't do any=20
optimization but every time clears some memory to black and repaints the

whole scene. But this is a fast process.

Yes, you can nest frames within frames.

Bruce Sherwood

Kuzminski, Stefan R wrote:

> My vpython app takes up 50% or so of the cpu just sitting there ( on a

> windows box ).  I put a sleep in my top level loop, but it didn't seem

> to help, maybe there is a thread eating up lots of cpu within vpython?
>=20
> also,
>=20
> Can I nest frames within frames?
>=20
> thanks,
>=20
> S

Re: [Visualpython-users] nested frames, cpu times

[Bruce S. <Bru...@nc...>]

Oops! I made a mistake. The 1% was with Jonathan Brandmeyer's new (but 
still somewhat experimental) Boost-based VPython. When I run the older 
Visual-2003-10-05 (the latest nonexperimental version) on a 1.4 GHz 
laptop, I see 40% CPU with lathe.py and 20% CPU with stonehenge.py (odd 
that stonehenge uses less CPU than lathe).

The renderer thread does sleep, so you won't see 100% utilization.

Bruce Sherwood

Kuzminski, Stefan R wrote:

> Hmm, Stonehenge takes ~20% of the cpu on my XP laptop. The date at the
> top of __init__.py is "Visual-2003-10-05".  Perhaps I will try a more
> recent release.
> 
> If that renderer thread doesn't sleep at some point in its loop, it will
> consume a lot of CPU just looping, but usually that behavior is to use
> 100% of the CPU.
> 
> thanks,
> S
> 
> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...] 
> Sent: Wednesday, May 12, 2004 5:11 PM
> To: Kuzminski, Stefan R
> Cc: vis...@li...
> Subject: Re: [Visualpython-users] nested frames, cpu times
> 
> That's odd. I ran lathe.py from the VPython demo suite and observed CPU 
> usage, which was less than 1% on a 2.6 GHz Windows XP machine. Note that
> 
> lathe.py makes a display and then ends. Even running stonehenge.py, 
> which has a continuous animation and looks for user mouse inputs, runs 
> at less that 1%. There is a rendering thread which many times per second
> 
> renders the scene, and it isn't "smart" -- it doesn't do any 
> optimization but every time clears some memory to black and repaints the
> 
> whole scene. But this is a fast process.
> 
> Yes, you can nest frames within frames.
> 
> Bruce Sherwood
> 
> Kuzminski, Stefan R wrote:
> 
> 
>>My vpython app takes up 50% or so of the cpu just sitting there ( on a
> 
> 
>>windows box ).  I put a sleep in my top level loop, but it didn't seem
> 
> 
>>to help, maybe there is a thread eating up lots of cpu within vpython?
>>
>>also,
>>
>>Can I nest frames within frames?
>>
>>thanks,
>>
>>S
> 
> 

Re: [Visualpython-users] nested frames, cpu times

[Jaap S. <j....@hc...>]

Bruce Sherwood wrote:
> Oops! I made a mistake. The 1% was with Jonathan Brandmeyer's new (but 
> still somewhat experimental) Boost-based VPython. When I run the older 
> Visual-2003-10-05 (the latest nonexperimental version) on a 1.4 GHz 
> laptop, I see 40% CPU with lathe.py and 20% CPU with stonehenge.py (odd 
> that stonehenge uses less CPU than lathe).
> 
> The renderer thread does sleep, so you won't see 100% utilization.
> 
> Bruce Sherwood
> 
> Kuzminski, Stefan R wrote:
> 
>> Hmm, Stonehenge takes ~20% of the cpu on my XP laptop. The date at the
>> top of __init__.py is "Visual-2003-10-05".  Perhaps I will try a more
>> recent release.
>>
>> If that renderer thread doesn't sleep at some point in its loop, it will
>> consume a lot of CPU just looping, but usually that behavior is to use
>> 100% of the CPU.
>>
>> thanks,
>> S

With the same Visual-2003-10-05 I get 99% CPU for pythonw.exe executing bounce2.py
on my 2.7 GHz XP laptop.
Starting an other session they share the CPU cycles 50% resp. 49%.

Jaaop Spies

Re: [Visualpython-users] nested frames, cpu times

[Jaap S. <j....@hc...>]

Jaap Spies wrote:

> With the same Visual-2003-10-05 I get 99% CPU for pythonw.exe executing 
> bounce2.py
[...]
> 
> Jaaop Spies
> 
My name is Jaap Spies

Re: [Visualpython-users] nested frames, cpu times

[Jonathan B. <jbr...@ea...>]

On Wed, 2004-05-12 at 21:04, Jaap Spies wrote:
> Bruce Sherwood wrote:
> >> Hmm, Stonehenge takes ~20% of the cpu on my XP laptop. The date at the
> >> top of __init__.py is "Visual-2003-10-05".  Perhaps I will try a more
> >> recent release.
> >>
> >> If that renderer thread doesn't sleep at some point in its loop, it will
> >> consume a lot of CPU just looping, but usually that behavior is to use
> >> 100% of the CPU.


Actually the renderer thread isn't running in a traditional for() or
while() loop.  It is being periodically called as a callback from a GUI
event loop - either Win32 on MS Windows, or gtk_main() on Linux and OSX.

> With the same Visual-2003-10-05 I get 99% CPU for pythonw.exe executing bounce2.py
> on my 2.7 GHz XP laptop.

The OS[1] will not reliably allow you to sleep for a time slice smaller
than 10 ms, so when the rate() function sees that you have less than 10
ms remaining before the rate() statement is to expire, it times it by
busy wait - it runs in a tight loop until the OS reports that the
remaining time is up.

Remember that the rate function attempts to ensure that you execute the
loop it is in at the requested rate - it is not a simple wait function. 
So, if you request a loop time of 10ms (such as the inner loop of
bounce2.py), your code will take up some of that time to run the loop
and the rate statement is forced to consume the rest by running in its
own loop rather than a sleep system call.  If you reduce the rate to
(say) 90 you will see the amount of CPU consumed drops considerably. 
For reference, it only consumes about 3% CPU on my aging 800 MHz PIII
when I do this.

> Starting an other session they share the CPU cycles 50% resp. 49%.

If you also look closely, you will see that the two running side-by-side
should have bouncing balls that move about as fast as one running
alone.  This is in spite of appearing to be halving the amount of
processing power available to each.

HTH,
Jonathan Brandmeyer

[1].  OK, technically, some OS's will allow you to wait for smaller
increments, and Linux will allow it in 1 ms increments if you are root,
but real-time operating systems aren't exactly the target platform for
VPython, and I wouldn't run VPython as root on my system even knowing
what it is doing! ;)

Re: [Visualpython-users] nested frames, cpu times

[Jaap S. <j....@hc...>]

Bruce Sherwood wrote:
> Oops! I made a mistake. The 1% was with Jonathan Brandmeyer's new (but 
> still somewhat experimental) Boost-based VPython. When I run the older 
> Visual-2003-10-05 (the latest nonexperimental version) on a 1.4 GHz 
> laptop, I see 40% CPU with lathe.py and 20% CPU with stonehenge.py (odd 
> that stonehenge uses less CPU than lathe).
> 
> The renderer thread does sleep, so you won't see 100% utilization.
> 
> Bruce Sherwood
> 

On my linux RH8.0 box bounce2.py takes 75-96% of the CPU, depending on
the load of other processes,
stonehenge.py seems to run for free: 0% , probably hidden in X.

Jaap Spies

Re: [Visualpython-users] nested frames, cpu times

[Jonathan B. <jbr...@ea...>]

On Wed, 2004-05-12 at 21:40, Jaap Spies wrote:

> On my linux RH8.0 box bounce2.py takes 75-96% of the CPU, depending on
> the load of other processes,

See my earlier comments about controlling the execution timing with
visual.rate().

> stonehenge.py seems to run for free: 0% , probably hidden in X.

Actually, if you are using the DRI, or one of the proprietary graphics
drivers, the only thing that X has to do to make VPython work is open a
window, pass mouse movement and button presses, and pass keyboard
clicks.  All of those are extremely cheap.  The OpenGL information is
passed almost directly to the video card, via the kernel, in batches.

HTH,
Jonathan Brandmeyer