[ODE] ODE in its own thread

[John Savage]

Threads are never going to magically speed up your code. They are only
useful if there is some part of your code that is blocking on an
external event (device I/O being the most common). 

I used multiple threads in an immersive VR engine I put together for a
final year project in college which rendered to multiple monitors and a
HMD (I used the VFX3D head mounted display with stereoscopic displays
and full head tracking). There was one thread for my physics and direct
input loop, and then there was one thread created for each graphics card
on the system. There was a central thread safe DB containing all object
position/orientation/state information that was written to by the
physics thread and read from by the render threads. Every thread had
it's own copy of this DB and updated it once per frame. This "lock and
copy" approach minimized contention for the single lock on the objects
DB. 

All this meant that the physics could render at >1000fps with really
small update periods to avoid tunneling problems and the graphics could
independently render as fast as it could, locking and grabbing a
snapshot of the current world every time around the loop. This system
ran on a dual PII 600 with a GeForce 1 as the primary AGP card and a PCI
TNT as the secondary card (this was back in 2000). Even with very
complex worlds, my physics ran at upwards of 3000fps (sometimes getting
up to 7000fps), the GeForce rendered at 200+fps and the TNT plodded
along at 60 to 70fps. It worked perfectly and won me quite a few awards.

A major problem with this threading system arises on a single processor
machine though. The physics/DI thread is CPU bound, so it always takes
the maximum thread time slice allocated to it by the OS. The rendering
threads are IO bound and get switched out every time they pause on a
render operation (which is quite often). This isn't a problem on a dual
system, because it results in one CPU being dedicated to the single
physics thread and the other CPU being shared by all rendering threads.
On a single CPU system it is a problem. When I first ran the system on a
single CPU PC my rendered FPS dropped to 10 or 15 while my render thread
stayed up at sky high rates of 1000+. A single Sleep(0) in my physics
thread fixed this to some degree, although framerates can still be
inconsistent. A better syncrhonisation method is required, but I haven't
worked on this engine for 2 years now :(.

Bottom line. Use mulitple threads ONLY if you have independent tasks
that will block, but can run concurrently. And also, be prepared for
some tricky performance problems due to syncrhonisation issues between
your physics and your rendering threads.

Hmmm. This started out as my 2 cents, but it turned into about 10 cents
worth of blabbering! I hope there is something useful in the above.

G'luck,
John


-----Original Message-----
From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf Of Alex
Hetu
Sent: Friday, August 01, 2003 11:15 AM
To: ode@q12.org
Subject: RE: [ODE] ODE in its own thread


I don't see much advantage in running ODE in its own thread. If your ODE
system is slow, the other threads will get affected by it somehow
anyway. The best way to speed up ODE is to wrap things up properly, use
spaces, and take advantage of the "NearCallback" that you pass when you
call dCollide or dCollide2. The fastest code is the one you simply don't
execute. The callback function simply allows you to skip TONS of tests.

The way you set up your ODE world and your NearCallback function are the
things that are going to determine how much processing ODE will take.

my world: NOT a landscape, 50k tris in ~1950 meshes, ~80 spheres and
boxes (some moving, some stalled), use dWorldStep and SimpleSpace, no
has or quadtree space. no slowdown, 60fps+. For the world geometry I
used something similiar to an octree, so it allowed me to set up a
hierarchy between the spaces. I could make my world 12 times bigger
right now and it wouldn't make one bit of a difference on processing.

Anyway, I think it's better having faster code than just tossing slower
code in another thread.

Alex


-----Original Message-----
From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf Of Patrik
Stellmann
Sent: Friday, July 18, 2003 8:18 AM
To: ode@q12.org
Subject: Re: [ODE] ODE in its own thread



> If I understood correctly you are simply simulating
>one thread run over several threads. Well.. why ?
>
Erm, not really, but by description was indeed pretty poor...
Nevertheless, the reason why only one thread at a time is running is
that only one at a time should have access to the world to avoid
conflicts. The ode-thread gives always to that trhead access having the
same simulated-real-time as the world has and does time steps as
necessary. The reason for having several threads is that the code for
the controllers should be the same as it would be on a real robot where
this synchronization with the 'world' wouldn't take place in that way
since there is no simulated time.

hope it was a little more clear or at least I no more look like a fool
;-) - but hey, it's my code :-)

Patrik


_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode

_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode