[osg-users] SingleThreaded leading to whole application just running on one core

[Sebastian Messerschmidt]

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 at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160926/f44e3cce/attachment-0003.htm>