Hi Robert,
Hi Tugkan,
I have certainly measured a performance improvement with the move to
using built ins, but it was only a couple of percent difference.
Your finding of a 20% difference when using thread safe ref/unref is
way beyond my own findings so perhaps the models you're testing have a
different composition than the ones I use for benchmarking. Does you
scene have lots of separate StateSet or Drawables or heavily loaded
with Transforms? The other possibility is that your build just isn't
coming together to provide as an efficient libs/binaries.
Yes the scene has many state sets and drawables. We heavily optimize our
scenes to reduce the number of state sets and drawables but going beyond
a certain point is not possible.
If I remember correctly, you also have the city model we are using for
benchmarking. I think last year we gave it to you.
I asked, but didn't get an answer, on what architecture and gcc you
are building on. This is important as I wish to see what is
particular about your build environement which might helps see why the
built ins aren't being detected, and why you're getting such bad
performance.
gcc version 4.2.1 , 32 bit Suse 10.3
Intel Core2 2.66GHz
tugkan
Robert.
On Wed, Dec 10, 2008 at 12:43 PM, Tugkan Calapoglu <[EMAIL PROTECTED]> wrote:
Hi Robert,
I changed cmake files to ignore automatic selection and choose
_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS. After a recompile I do not see a
difference in the performance. I dont have any experience with GCC builtins
so I don't know if this can be normal.
In my tests I observed that for this model and camera position
enabling/disabling thread safe ref/unref makes around 20% performance
difference. I thought GCC builtins should reduce this.
Tugkan
Robert Osfield wrote:
Hi Tugkan,
On Mon, Dec 8, 2008 at 11:04 AM, Tugkan Calapoglu <[EMAIL PROTECTED]>
wrote:
With printf's I ensured that the mutex code was not called in ref() and
unref(). Here are the results (removed printfs before measurement :) ):
No ref_ptr : ~1.15 ms
ref_ptr but thread safety off : ~1.35 ms
ref_ptr with thread safety on : ~1.65 ms
I was focused on cull so I didn't write down what happens with draw.
What are model are you measuring for the above results, it seem like
very short cull times, and not worthy of optimizing, so I presume this
is for a very small test case. If the performance looks like it's
going to break frame then worry about it, so in that vain could you
try throwing at the system a model that breaks frame/or near breaks
frame due to cull.
The model in question is a small sized city. What worries me is, of
course, not the 1.65 ms but the change from 1.15 to 1.65. We use this model
for benchmarking but we delivered much larger databases to customers where a
performance loss of this size would bring us well under 60Hz.
I made these tests with SVN revisions 7327 and 7328 so things may be
different now. But using pointers instead of ref_ptr seems to be better
for
performance.
What kind of restrictions would using c pointers require?
The danger in using C pointers come from when you are running the
DrawThreadPerContext/ CullThreadPerCameraThreadPerContext threadings
model dynamically removing StateSet and Drawables from the scene
graph. This threading models are allow the draw thread to overlap
with the update, event and cull traversals of the next frame, so it's
possible to modify the scene graph in a way that deletes objects that
are still being drawn which results in a crash.
A follow up problem can occur once you exit the frame loop, as you may
delete the scene graph before the draw threads have completed the last
draw traversals.
Since the OSG is used in some many different types of applications we
need to make sure the defaults are robust across a wide range of usage
models, so in this case the ref_ptr<> in the rendering backend is
essential.
We intend to use CullThreadPerCameraThreadPerContext or
DrawThreadPerContext on multi core machines. I guess for this type
applications ref_ptr version would be required anyway.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Tugkan Calapoglu
-------------------------------------
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone +49.8031.463641
fax +49.8031.463645
email [EMAIL PROTECTED]
internet www.vires.com
-------------------------------------
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein HRB 10410
Geschaeftsfuehrer: Marius Dupuis
Wunibald Karl
-------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Tugkan Calapoglu
-------------------------------------
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone +49.8031.463641
fax +49.8031.463645
email [EMAIL PROTECTED]
internet www.vires.com
-------------------------------------
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein HRB 10410
Geschaeftsfuehrer: Marius Dupuis
Wunibald Karl
-------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
