Hi Robert,
> Check the CMAKE_CXX_FLAGS_RELEASE, it should read something like -O3,
CMAKE_CXX_FLAGS_RELEASE is set to -O3 -NDEBUG so thats ok I think.
>Potentially we could make the use of ref_ptr<> in the rendering back
>optional offering the faster but less robust using C pointers -
>perhaps a cmake build option, but it'll complicate the code a bit and
>require a little know knowledge from the application developer about
>the restrictions that such a change introduces.
In my comparison tests I observed that using ref_ptr even though thread
safe ref/unref is *turned off* results in a significant increase in cull
time. 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.
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?
>I'll have to defer to Mathias Froehlich on how best to detect the
>support for atomic ref counting as he's the author of the detection
>code.
Ok, thanks.
>What gcc version do you have on your system? Are all your systems 32
>or 64bit?
gcc version 4.2.1 , 32 bit Suse 10.3
thanks tugkan
HI Tugkan,
I used standard configure with "cmake . -DCMAKE_BUILD_TYPE=Release" .
Check the CMAKE_CXX_FLAGS_RELEASE, it should read something like -O3,
I mention this as I had found that CMake 2.6.0 pulled down from the
Ubuntu 8.10 repositories erroneously left this field blank.
include/OpenThreads/Config has
_OPENTHREADS_ATOMIC_USE_MUTEX
instead of
_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS
This is likely to be a large part of why you aren't getting the
performance that isn't as good as it should be. When I did introduce
the ref_ptr<> into the rendering backend I this was when we still just
had mutex based ref_ptr<> and while there was a small performance hit,
was at most only a couple of percent with vsync off. The change was
introduced for robustness reasons - as the code required to prevent
crashes when users deleted objects during the
DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext modes
with rather awkward and prone to bugs.
Potentially we could make the use of ref_ptr<> in the rendering back
optional offering the faster but less robust using C pointers -
perhaps a cmake build option, but it'll complicate the code a bit and
require a little know knowledge from the application developer about
the restrictions that such a change introduces.
I tried to debug this. Here are my observations:
1- In CheckAtomicOps.cmake some small programs are compiled and run to see
whether the architecture supports GCC_BUILTINS. I copied and pasted the one
for GCC_BUILTINS to a file and tried to compile it. If I compile with "g++
test.cpp" I get following errors:
test.cpp:(.text+0x43): undefined reference to
`__sync_bool_compare_and_swap_4'
test.cpp:(.text+0x6e): undefined reference to
`__sync_bool_compare_and_swap_4'
If I explicitly define an architecture as follows, "g++ -march=i686
test.cpp", then compile succeeds and the resulting program runs and returns
successfully.
2- I changed the CheckAtomicOps.cmake so that the results of the test
programs are completely ignored and SET(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS
1) is called in any case. This successfully changes
include/OpenThreads/Config to use _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS.
However, when I try to compile OSG I get linker errors similar to the above
ones.
3- It can be seen in CMakeFiles/CMakeSystem.cmake that the architecture is
correctly recognized as i686 ( SET(CMAKE_SYSTEM_PROCESSOR "i686") line is
present ).
4- I saw on a different Suse 10.3 computer that it also
has_OPENTHREADS_ATOMIC_USE_MUTEX.
I don't have much experience with cmake system so I don't know how I should
continue with debugging. Can you give me some pointers?
I'll have to defer to Mathias Froehlich on how best to detect the
support for atomic ref counting as he's the author of the detection
code.
What gcc version do you have on your system? Are all your systems 32 or 64bit?
Robert.
_______________________________________________
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
