Hi Ulrich, On Thu, Dec 4, 2008 at 1:32 AM, Ulrich Hertlein <[EMAIL PROTECTED]> wrote: > My take on hyper-threading was always to disable it, if enough (say >= 4) > cores > are available. It's not a separate core after all and there is a certain > amount of work involved to make one core look like two.
For threads that don't have critical latency like file reading threads hyper threading actually makes a lot of sense as the processor core won't be highly contended - much of the times the paging threads will be stalled waiting for IO. For performance critical threads like cull and draw dispatch one will need to take care about dropping two threads on to a core that will contended at the same time for its resources. > Additionally: what is the communities' experience with manually assigning > processes to cores? Does it work? Yes, it's pretty important for multi-processor performance gains, even under Linux as an move of the thread from core to core throws invalidates the cache. Thread affinity can make the difference of multi-threaded viewer being faster or slower than a SingleThreaded. Performance I've seen on this machine suggests a bit of mixed bag, with desktop effects on I found that DrawThreadPerContext viewer didn't perform better than SingleThreaded, but with desktop effect off performance was much better with DrawThreadPerContext. This is just with a few limited tests, and no new controls on thread affinity to take account of the hyper-threading, I have much to learn yet about the dynamics yet. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
