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
