On Wednesday 21 November 2007 02:49:18 Robert Osfield wrote: > It might be easier just to dual boot linux and then use linux as a way > of testing things with a totally different environment. Testing on > multiple OS with multiple compilers is a good way to shake down bugs.
I have found that given the same hardware, the load time for files is literally double on Windows what it is on Linux. In my case, I am running a 64 bit Linux system and a 32 bit Windows system, which might account for some of the speed difference. However, I truly believe that the performance difference between Windows and Linux is primarily due to differences in the STL implementations, and I believe that STLport is the best way to fix that on Windows. I have put together some test projects (non-OSG) with STLport that show an approximate 30% improvement in load speed on Windows. STLport does provide a slight speed advantage on Linux as well, but the improvement is only a few percent. It is important to note that these results are based on release mode performance. Debug mode is much harder to characterize, as Microsoft STL and STLport both use checked STL implementations (a very good thing), and gcc does not (unfortunately). The STLport checked STL implementation seems to be more thorough, but it also runs slower than the Microsoft STL. Most of the STL is a header-only library. Many implementations allow setting defines to configure the implementation. Libraries and executables that rely on the STL and include STL types in the interface should be compiled with the same configuration. The checked STL configuration is not compatible with the optimized configuration. This is the reason why debug libraries are specifically required to link to debug executables in Windows. On Linux with the gcc STL, it is not a problem to link release libraries to a debug executable. A change in STL implementation (on any platform) will require rebuilding all libraries that utilize an interface with STL types. For instance, OSG passes std::string as part of its interface; therefore is has a STL interface. On the other hand, QT has its own string class. As far as I can tell, QT would not have to be recompiled with STLport support, but OSG would. I am still trying to get funding in order to do a porting effort to STLport in our software. If that happens, I will be able to provide better numbers. Justin _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
