[ODE] ODE in its own thread

Sat Jul 19 03:40:10 2003

This is a multi-part message in MIME format.
--------------060800040407040201020803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ok, trying to clearify it once more: I'm *not* using several threads 
because I believe it could magically make my code faster. As I already 
said most threads are waiting for another anyway so there is in fact 
pretty low 'parallel' computation. But since I want provide an interface 
that can be impelmented on real robots as well I simply need to support 
multi threading (at minimum one per robot) so this all is about design 
and not performance...

Alex Hetu wrote:

>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
>
>  
>

--------------060800040407040201020803
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Ok, trying to clearify it once more: I'm *not* using several threads
because I believe it could magically make my code faster. As I already
said most threads are waiting for another anyway so there is in fact
pretty low 'parallel' computation. But since I want provide an
interface that can be impelmented on real robots as well I simply need
to support multi threading (at minimum one per robot) so this all is
about design and not performance... <br>
<br>
Alex Hetu wrote:<br>
<blockquote type="cite"
 cite="midHIEEJEPLDEGFJKJIFBPPMEHGCAAA.alexhetu@videotron.ca">
  <pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:ode-admin@q12.org">ode-admin@q12.org</a> [<a class="moz-txt-link-freetext" href="mailto:ode-admin@q12.org">mailto:ode-admin@q12.org</a>]On Behalf Of Patrik
Stellmann
Sent: Friday, July 18, 2003 8:18 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:ode@q12.org">ode@q12.org</a>
Subject: Re: [ODE] ODE in its own thread

  </pre>
  <blockquote type="cite">
    <pre wrap="">If I understood correctly you are simply simulating
one thread run over several threads. Well.. why ?

    </pre>
  </blockquote>
  <pre wrap=""><!---->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
<a class="moz-txt-link-abbreviated" href="mailto:ODE@q12.org">ODE@q12.org</a>
<a class="moz-txt-link-freetext" href="http://q12.org/mailman/listinfo/ode">http://q12.org/mailman/listinfo/ode</a>

_______________________________________________
ODE mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ODE@q12.org">ODE@q12.org</a>
<a class="moz-txt-link-freetext" href="http://q12.org/mailman/listinfo/ode">http://q12.org/mailman/listinfo/ode</a>

  </pre>
</blockquote>
</body>
</html>

--------------060800040407040201020803--