Thread: [Visualpython-users] VPython and Pentium 4 HT conflict

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Jonathan
    This will be a rather long message as I am attaching some of our 
correspondence of mid-August.  The problem was (and still is with the Nov 
04 release) that my application using the new VPython will run fine on a 
standard P4 but when run on a P4 with HT will run for several to a dozen or 
so iterations before crashing and getting the "send error to MS" window. 
Reverting to the old (Nov 03) VPython eliminates this problem.

The conversation ended with (at least in my mind) the problem being some 
conflict between the Pentium hyper-threading and the Visual Python 
libraries that hopefully would be resolved with a newer release.
BTW -- the app (with the Nov 03 VPython libraries) is at 
www.terastat.com/VisualFilter.htm, as I mentioned it's rather complex -- I 
can stick a version with the new VPython out on the web if you're interested.

Bruce Peterson

 >>>Snip<<<<

>Do you know if the problems with Intel's Hyper Threading processors were
>fixed in this release?
>
> >>> Snip <<<<
>
>I can't recall the details of the discussion that I think you are
>referencing - can you refresh my memory?
>
>Thanks,
>-Jonathan

On Wed, 2004-08-11 at 13:45, Bruce Peterson wrote:
 > Jonathan-
 >   I'm sending this to you rather than the Visual Python list because this
 > is not (I
 > think) directly a Visual Python problem. I'm hoping your experience in
 > debugging
 > across multiple platforms may provide some insight.
 >
 > I have a fairly complex app that uses a client-server architecture with 
Visual
 > being run in a threaded server and controlled by a client interface. This
 > allows

Are the client and server programs running as separate processes or as
multiple Python interpreters within the same process?

 > changes to a Visual animation to be made on the fly.

Sounds pretty cool.  IIRC, you went with this design because VPython
didn't support event-loop based GUI programs, right?

It may interest you to know that the next major release of VPython will
contain an object tentatively named "display_kernel".  It manages all of
the GL scenegraph-like functionality, while not including any windowing
system-specific code.  The idea is that you can wrap around or inherit
from this class to provide toolkit-specific windowing and GL context
management to create a custom display object.

If you happen to know some C++, you might want to look at the
'vpython-core2' module in CVS.  It doesn't completely quite work in
Windows yet, and doesn't include bindings to Python, either, but they
are coming soon.  The files of most interest in this matter are
include/display_kernel.hpp and src/core/display_kernel.cpp

 >  To distribute this app, I
 > use Py2exe to roll it into an executable (plus all the support files Py2exe
 > finds)
 > and then use the Wise installation system to make a distributable.
 >
 > When I installed the new Visual Python upgrade, I went through the above
 > falderal and then tested on multiple machines. My development box is WinXP
 > and I
 > also tested another WinXP box and a virtual WinXP (using the VirtualPC
 > emulator) machine. I also tested on a Win2K box and a virtual Win2K
 > machine. All
 > worked as expected.
 >
 > The problem is a WinXP  notebook. When I run the VisualPython animation 
on the
 > notebook WinXP -- it runs for awhile then crashes  to the Windows error
 > reporting
 > dialog. From the variable run time to crash I think it may be related to
 > garbage

About how much time does it take to crash: right away, a few seconds,
several minutes?  If you are running the program with some set of
delays, like rate() or blocking read(), does removing them cause the
test case to crash proportionally faster?

 > collection-- but why only on this one machine escapes me.
 > If it was a dll
 > being
 > omitted in the distribution I would see problems on the other test
 > machines.

It most likely would fail to start at all, with a very different error.

 >  Of
 > course simpler test programs don't have this problem (the problem app 
does data
 > animation with fairly large arrays of data in memory).

Are you using Numeric for these arrays or some custom type?

Are you using curve, convex, or faces?  If so, are you performing
appends, block operations, or both?

 > The previous version of Visual didn't have this problem, so it does appear
 > to be somehow
 > related to the new version of Visual.
 >
 >
 > Any insights would be appreciated.
 >
 > BTW -- good work on maintaining and upgrading Visual Python -- its by 
far the
 > easiest tool for creating 3D animations I've run across.

 >  I would hope that the next version would be able to use the hardware
 > acceleration available on many graphics cards. It appears that
 > currently  Vpython is running "generic" for compatibility, which means
 > having a high end graphics card does no good for increasing speed.
 > Hardware acceleration may allow effects like variable transparency to
 > be implemented.

The hardware support stuff is already done :)  Most of the objects
support translucency, with the current exceptions of ring, curve,
convex, and faces.  (convex may support it before I'm done).

 > > Are you using curve, convex, or faces?  If so, are you performing
 > > appends, block operations, or both?
 >
 > I use curve directly but not convex or faces. I use curve to show a
 > variable length history of prior states so I'm continually appending
 > and slicing the curve. Again the history length is user controllable
 > so one option is no history -- and this doesn't appear to affect the
 > crash rate.
 >
 > One other difference I've noted is that the notebook is the newest of
 > the machines and uses "hyper threading" -- I would think any such
 > hardware threading would be below the level of user programs and
 > therefore transparent -- but maybe not.

It is semi-transparent.  The result of running VPython on an HT-enabled
P4 is that the render and Python threads run truly simultaneously rather
than merely asynchronously.

Are the curves "thin", or do they have some radius set?

Thanks,
-Jonathan
 > >
 > >It is semi-transparent.  The result of running VPython on an HT-enabled
 > >P4 is that the render and Python threads run truly simultaneously rather
 > >than merely asynchronously.
 >
 > Well its looking more and more like the problems are due to the HT-P4 and
 > how it handles VPython. Using the old VPython (oct 2003), I can launch
 > multiple copies of the client, and the server will create multiple,
 > synchronized, Vpython displays -- this on a Dell Xeon 2.1 GHZ processor.
 > When I attempt to do this on the P4-HT notebook -- only the first instance
 > runs, the second can't find the server.
 > One on the joys of Python is that I can run my server code as a standalone
 > application (for testing) with no code changes. When I do this, I can run
 > two copies on both the Xeon and P4-HT machines.  So it appears that
 > software threading has problems on the P4-HT -- and the new VPython
 > aggravates these.

Since the language binding between Python and C++ was completely
replaced, some functions are a little slower, and a few functions are a
pinch faster than before.  This small difference in timing (plus the
availability of an HT Pentium and a dual-proc PowerMac) exposed several
latent threading bugs in VPython during development.  At least one is
still unresolved (stereo displays may be blank under unknown
conditions).

Thread: [Visualpython-users] VPython and Pentium 4 HT conflict

This project is no longer active. See vpython.org.

visualpython-users