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