[osg-users] SingleThreaded leading to whole application just running on one core
Robert Osfield
robert.osfield at gmail.com
Tue Sep 27 09:10:19 PDT 2016
Hi All,
I have now implemented the new OpenThreads::Affinity class in Windows,
this is now checked in the the openthreads_affinity_mask branch.
at the same time I spotted a missing feature - I'm not the author of
OpenThreads and hadn't need to touch the Win32 implementation before
so hadn't looked at (I'm a linux dev 95% of the time). The missing
feature was setting the affinity for the current thread when the
current thread isn't an OpenThreads thread. This missing feature
meant unix (pthreads) vs windows was behaving different w.r.t the
osgViewer setting the affinity of the main thread. Now that I've
implemented this missing feature we should see the same behaviour.
Another inconsistency that I will be investigating next is the setting
the affinity of main thread when running the viewer multi-threaded vs
single-threaded. Both by default should do exactly the same thing and
set the affinity of the main thread to core 0. This is needed for
performance reasons.
One approach I'm considering is putting an OpenThreads::Affinity
object into osgViewer::VIewerBase so that this can be used to set the
affinity of the viewer's main thread. I'm also considering doing
something similar for osg::GraphicsContext::Traits and
osgDB::DatabasePager to provide a means of user specifying what
affinity they want. In the case as the database pager you would
typically want a pool of database paging threads that you give the
same affinity to, such as have them all sit on cores 4,5,6,7, while
the main viewer threads sit on cores 0,1,2,3 etc. I'm just giving
examples of how it could be laid out.
If doing the above is viable to implement then potentially one could
set the Affinity object for the viewer to allow the main thread to run
on all threads and therefore allow the usage case discussed earlier in
this thread. While it might be possible to get the OSG to work this
way, it's not something I would recommend at all. Not setting
affinity is bad for performance, I wouldn't want to encourage users to
end up with poorly performing applications because we have the
opportunity to totally ignore process affinity. My goal with is to
get the OSG to perform well out of the box as far as possible, this
has been what the OSG has been around since it's inception, using
sensible affinity setting out of the box is part of this.
Robert.
More information about the osg-users
mailing list