Hi Robert,
I
Hi All,
I have taken Christoph's test problem and reproduced the affinity
issue on my Kubuntu 16.04, so this is useful first step.
I've also reviewed the OpenThreads code, so have a better idea of the
code in question. Please note that I'm not the author of OpenThreads,
the project just fell on my shoulders to maintain. Some of the code
in OpenThreads pthread side made me curious so I modified Christoph's
code to added a code path using OpenThreads rather than C++11 threads
used in Christoph's code and command line options to toggle between
the two, toggle beteween viewer running SingleThreaded or with
defaults (will be DrawThreadPerContext). Attached is a CmakeLists.txt
file and main.cpp.
For the OpenThreads pathway I get the exactly the same performance
when running the viewer single theaded or multi-threaded.
time ./threadtest --ot --SingleThreaded
Thread 0x142df50 done
Thread 0x1427750 done
Thread 0x1427690 done
Thread 0x142dcf0 done
Thread 0x142e1f0 done
Thread 0x142e0a0 done
Thread 0x142edc0 done
Thread 0x142e5e0 done
Thread 0x142ec70 done
Thread 0x142e9d0 done
Thread 0x142e340 done
Thread 0x142e490 done
Thread 0x142de20 done
Thread 0x142e880 done
Thread 0x142e730 done
Thread 0x142eb20 done
real 0m15.463s
user 1m59.612s
sys 0m0.044s
For the C++11 threads I get far worse performance when running single
theaded vs multi-threaded:
$ time ./threadtest --SingleThreaded
Thread 7 done
Thread 11 done
Thread 10 done
Thread 13 done
Thread 12 done
Thread 6 done
Thread 9 done
Thread 8 done
Thread 14 done
Thread 15 done
Thread 5 done
Thread 4 done
Thread 3 done
Thread 2 done
Thread 1 done
Thread 0 done
real 1m22.315s
user 1m22.064s
sys 0m0.044s
So the code in OpenThreads to set the affinity mask by default for
it's own threads resolve the issue completely (note, the
OpenThreads::Thread that I created above don't set affinity, so they
are free for the OS to place them.) This may also be why most users
don't see these issues.
This isolates the issues to users who use non OpenThreads threads when
these threads are created after the viewer has been realized and don't
set thread affinity for there threads themselves. That's three sets
of conditions that any one be changed and the problem will be entirely
resolved.
The problem as Christoph mentioned are threads which are created by
C++11 features such as std::async. One simply doesn't have any control
over them and cannot set any affinity whatsoever.
While not ideal that this issue exists at all at least we now have a
handle on it. Given the issue only occurs with a very specific set of
usage I don't think there is any reason for sweeping changes to the
core OSG, or changes to the defaults.
Would a small function to enable/disable the affinity in SingleThreaded
mode be a big breaking change? Defaulting to using the affinity mask,
making it up to the advanced user to sacrifice the performance.
I would argue that the the issue isn't that specific when seen in a
greater context. In my case OSG is used behind an interface, so it might
not be possible to use create threads before the viewer.
Also it simply feels like an inappropriate side-effect which is buried
without having control/access over/to it.
Cheers
Sebastian
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
