On Tue, Apr 2, 2019 at 4:33 PM Robert Osfield <robert.osfi...@gmail.com> wrote: > > Hi François > > Thanks for the suggestion and links. I had been wondering about there > was an issue with thread affinity and your links illustrates how this > can be even worse than normal with the two group of cores on the > Ryzen. > > I have followed your suggestion of using taskset to set the affinity > to -c 0-7 and various other combinations but don't see any consistent > difference to be able to declare that it's having a positive affect - > the variation in frame rates between different runs is wider than any > differences using taskset has. I've been trying runs of the same > software (osgviewer & osg2vsg viewer) and with the same dataset on my > Intel and AMD boxes with different taskset and if anything the Intel > benefits more, and the results are perhaps slightly more consistent. > Differences are in the 1-2% range, but each run I can see as much > variation as this so I'd say the results are statistically > significant. > > The tests I've been doing just now use an old city model that I have, > it's not a large model and doesn't use any advanced features being > derived originally from a Creator/OpenFlight model. Total number of > Geometries is 2268, number of Group nodes 1518, Transforms 552, > Vertices and Primtives 161,061 and 46,396 respectively and finally > 1105 StateSet's. When using the same animation path file, and > rendering at 192x108 (1/100th pixels of my display to avoid fill > limit) this small city model renders at: > > OSG OSG(vfs) VSG > core-i7-4770s 672fps 432fps 2845fps > AMD 2700 547fps 347fps 2320fps > > The OSG(vsg) is running osgviewer with just view frustum sides enabled > so that small feature culling is not enabled. This makes quite a bit > of difference to the OSG performance on this model, so switching it > off rather hobbles the OSG for this dataset and animation path but as > the VSG doesn't have small feature culling or LOD it's a bit of better > comparison like for like with the VSG. The OSG in these case are > running with DrawThreadPerContext while the VSG is running single > threaded. > > The OSG with small feature culling results see a 22% slow down on the AMD > 2700. > The OSG with small feature culling off see a 26% slow down on AMD 2700 > The VSG sees a 22% slow down on the AMD2700 > > This is all despite having a Geforce 2060 in the AMD box vs a 1060 in > the Intel one, so it's looks strongly like a CPU related issue and a > pretty consistent once given we have two totally different scene > graphs exhibiting a similar slow down. > > For those curious about how much multi-threaded helps the OSG. > Running Single threaded the results I get are: > > OSG OSG(vfs) VSG > core-i7-4770s 483fps 322fps 2845fps > AMD 2700 399fps 256fps 2320fps > > So DrawThreadPerContext vs SingleThread with small feature culling is > 39% faster on the Intel, 37% faster on the AMD. > While DrawThreadPerContext vs SingleThread without small feature > culling is 34% faster on the Intel, 35% faster on the AMD. > > The figures for the VSG are the same in the above tests as I haven't > yet tackled multi-threading. The VSG also doesn't yet do depth > sorting of the transparent objects or do billboarding so it's not > quite a 1:1 match up for visuals, these features will slow the VSG by > some %, while multi-threading will get us back some. The VSG hasn't > been optimized either so it's too early to make any conclusion from > the figures beyond comparing Intel vs AMD and that the VSG with Vulkan > is going to be significantly faster than the OSG/OpenGL for models > that have lots of separate geometries and state. > > Another oddity is that in the osg2vsg test app I've added a test of > not fulling in the command buffer each frame, instead just > resubmitting the same command buffer each frame, when I do this I > remove the VSG's command dispatch traversal. It doens't update the > eye point so it's a pretty crappy test in terms of something that is > widely useful in real applications but it can provide some insight in > the CPU overhead associated with the scene graph traversal and filling > the command buffer. On the Intel system I see frame rate jump from > 2800fps to 6700fps, while on the AMD system frame rate stays around > 2200-2300fps point and if anything it actually averages slightly lower > fps. This is a really odd result on the AMD system and suggest that > perhaps the driver/OS is doing something odd as I'm running exactly > the VSG version and data on both systems. > > At this point I'd love to get some better performance parity between > Intel and AMD as a ~25% penalty is far larger than I was expecting. > Yesterday I tried out clang-7 on my AMD box and didn't spot any > notable differences with gcc 8.2. Now taskset suggests that thread > migration between cores is not a significant issue for the these > particular scene graph tests under Linux. > > Where to look next? Happy to take suggestions.
I'd disable SMT next. However note that the Haswell CPU mentioned above not only has a good IPC even for today but runs close to 4GHz with Turbo. In other words it is no slouch and I would expect it to be competitive with Ryzen except for core count and maximum RAM amount and maybe to beat it for workloads not using 6+ cores on Ryzen. If you want to compare CPU performance between those two boxes outside of OSG, use http://download.amd.com/demo/RyzenGraphic_27.blend with Blender, instructions available at https://www.pcworld.com/article/3151464/you-can-find-out-how-your-cpu-compares-to-amds-ryzen-for-free.html Be sure to use the same Blender build and settings. You might be surprised. François > I'm now going to install Kubuntu 18.04 on the AMD system to see if > 18.10 and the later NVidia drivers are both having an negative effect. > > Cheers, > 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