Re: [osg-users] std::vectorbool performance issue
You can try to use OSG_BUILD_KDTREES=on env var or turn it on in your program, also u can try using osg optimizer with SPATIALIZE_GROUPS option if u dont actually need (or can work some way around) initial graph structure. Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31555#31555 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
Robert, You are right, although vectorbool is slow, it is apparently not the bottleneck. In my case, the bottleneck was basically, a deep and complex hierarchy of osg::Switch groups. I did some frame rate testing, replace all the osg::Switch with osg::Group, then frame rate tested again. There was only a minor difference. The hierarchy is the issue, not the presence of the osg::Switch Still, this is a bit like the _SECURE_SCL=0/1 issue on Windows - a performance problem possibly waiting to bite someone. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31382#31382 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
Just as background, the model is a CAD model of a fairly typical part. When broken down to the component CAD entities, there are a total of about 19,000 groups in a hierarchy about 4 levels deep. Of course the geometry could be coalesced to any level, but users expect visibility control and attribute control down to the individual entity level. The traversal of the scene graph is very significant portion of the time taken to refresh the scene. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31386#31386 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
Hi Andrew, On Tue, Sep 7, 2010 at 4:25 PM, Andrew Cunningham o...@a-cunningham.com wrote: Just as background, the model is a CAD model of a fairly typical part. When broken down to the component CAD entities, there are a total of about 19,000 groups in a hierarchy about 4 levels deep. Of course the geometry could be coalesced to any level, but users expect visibility control and attribute control down to the individual entity level. The traversal of the scene graph is very significant portion of the time taken to refresh the scene. If the large number of internal nodes in the scene graph is the bottleneck then perhaps it would be appropriate to simplify it using custom nodes that can manage the specifics of your type of scene layout. OOoo just had an almighty lighting strike and thunder just outside my window... time to stand back from any electrics... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
On 9/7/2010 9:25 AM, Andrew Cunningham wrote: Just as background, the model is a CAD model of a fairly typical part. When broken down to the component CAD entities, there are a total of about 19,000 groups in a hierarchy about 4 levels deep. Of course the geometry could be coalesced to any level, but users expect visibility control and attribute control down to the individual entity level. The traversal of the scene graph is very significant portion of the time taken to refresh the scene. I would consider using some sort of dynamic building of the model. Build the scenegraph with only the top-level groups, flatten everything below them. If the user performs and action that needs finer grained division (like, drilling into one of the groups) then you can replace the flattened subgraph with a newly-built subgraph with fine-grained grouping. either all the way down, or just down to the next step, and repeat the process when/if they drill into that layer. For picking, you should be able to have a unique ID on every leaf node, regardless of whether it's in a group or not. Paul Martz of Skew Matrix could write a book about don't use OSG to simply recreate your application's internal geometry structure. Andrew -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
Hi Tom, The ValueList in osg::Switch is a std::vectorbool for readability reasons - it's obvious what it relates to. You report of using Switch nodes slowing performance is surprising - the first report of this issue in the history of the OSG project, so you are either more Switch nodes than anyone else, your compiler is now doing a very poor job at optimization or perhaps you're just a better detective and are the first to pinpoint the problem. Is the performance slow down something you see under release build? Or so it'd look to be a real issue. The next step after this would then be to change the ValueList defined in Switch to std::vectoruint and then do the testing again. As a general note, typically our cull traversals are bandwidth limited rather CPU limited, so using memory more efficiently and avoiding cache misses is more critical than local optimizations. Robert. On Fri, Sep 3, 2010 at 11:27 PM, Andrew Cunningham o...@a-cunningham.com wrote: Hi, I am looking at a performance slow-down introduced after using some osg::Switch groups. I did some performance benchmarking on std::vectorbool and I found push_backs are 10x slower than std::vectorint, and more importantly, the simple [] operator is about 20x slower(*). I am not sure it is the smoking gun yet, as I will need to back-track a lot of code, but it looks possible. This is because std::vectorbool is specialized in the STL to be a memory efficient packed vector. I am not so sure that the memory (bool vs say unsigned char ) saved is really worth the performance hit in the case of osg::Switch (* Win32, _SECURE_SCL=0, Studio 2008) Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31323#31323 ___ 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
Re: [osg-users] std::vectorbool performance issue
Hi Andrew, I suggest you read Scott Meyer's book - Effective STL - Item #18: Avoid using vectorbool I was able to find the book online at: http://www.uml.org.cn/c++/pdf/EffectiveSTL.pdf Cheers, Erik On 04-09-2010, at 00:27, Andrew Cunningham wrote: Hi, I am looking at a performance slow-down introduced after using some osg::Switch groups. I did some performance benchmarking on std::vectorbool and I found push_backs are 10x slower than std::vectorint, and more importantly, the simple [] operator is about 20x slower(*). I am not sure it is the smoking gun yet, as I will need to back-track a lot of code, but it looks possible. This is because std::vectorbool is specialized in the STL to be a memory efficient packed vector. I am not so sure that the memory (bool vs say unsigned char ) saved is really worth the performance hit in the case of osg::Switch (* Win32, _SECURE_SCL=0, Studio 2008) Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31323#31323 ___ 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
Re: [osg-users] std::vectorbool performance issue
Erik, I think if Andrew could avoid it he would, but Code: typedef std::vectorbool ValueList; is built into osg::Switch. Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31329#31329 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vectorbool performance issue
I understand, but I thought that Andrew identified a performance issue that could potentially be solved by modifying osg::Switch (or perhaps creating a custom node similar to switch) and possibly making a subsequent osg-submission, so I wanted to give him some context for that. That's all,... Erik On 04-09-2010, at 17:56, Tom Pearce wrote: Erik, I think if Andrew could avoid it he would, but Code: typedef std::vectorbool ValueList; is built into osg::Switch. Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31329#31329 ___ 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
[osg-users] std::vectorbool performance issue
Hi, I am looking at a performance slow-down introduced after using some osg::Switch groups. I did some performance benchmarking on std::vectorbool and I found push_backs are 10x slower than std::vectorint, and more importantly, the simple [] operator is about 20x slower(*). I am not sure it is the smoking gun yet, as I will need to back-track a lot of code, but it looks possible. This is because std::vectorbool is specialized in the STL to be a memory efficient packed vector. I am not so sure that the memory (bool vs say unsigned char ) saved is really worth the performance hit in the case of osg::Switch (* Win32, _SECURE_SCL=0, Studio 2008) Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31323#31323 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
