Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Goober5000 on October 05, 2013, 01:52:01 pm
-
I've heard good things about the STLport (http://www.stlport.org/) library that replaces the default STL implementations shipped with Visual Studio. (STLport is already part of the Visual Studio 6 project files, because Microsoft's implementation of STL for Visual Studio 6 didn't include some classes that were added later.)
In addition to STLport's wide support for different compilers and platforms, it also advertises a significant speedup over default implementations. So I'd like to put that claim to the test. I've built two versions of FSO from the latest revision in SVN (9872 as of this post), and I've uploaded them so that people can compare them directly...
Standard builds (http://staff.hard-light.net/goober5000/temp/MSVC2005-r9872.zip)
Builds using STLport (http://staff.hard-light.net/goober5000/temp/MSVC2005-r9872-STLport.zip)
If STLport does offer a significant speedup, you should see a difference where collection libraries are used extensively, such as in missions with a lot of potential object collisions (e.g. dense asteroid fields) or with numerous ships and effects being rendered.
-
STLport is basically an abandoned project (last release in 2008) and all the other implementations of STL don't stand still, waiting for it to become relevant again. And we're talking both performance and feature wise (C++11 anyone?). What I find kinda amusing (and a little sad) is the usage of MSVC 2005, when you have 2013 available for free, with all the advancements accumulated over the years, which would trample the potential benefits (if any!) to be gained from using STLport.
-
The free (Express) versions of MSVC, while free, don't have all the feature sets of the non-free and not trivially cheap versions have to offer.
To whit, there is not (that I'm aware of) any "free" version of MSVC that can compile FRED. And making it possible for a free version to be able to do so is a grey can of worms at best. Now, this won't be an issue so much once wx_FRED is functional, but somebody at some point is still going to need to be able to compile and validate features and what not under FRED2Open itself for some time to come.
That's just -one- limitation. If I were to count the amount of changes that would take place in migrating to MSVC 2013 Express from 2008 Team Suite, I imagine there would be a lot of differences.
For the record, I love forward progress. But not when it is a case of "simply for the sake of". While I agree that we need to worry less about supporting ever aging constructs, we can't keep throwing the baby out with the bathwater on every new release of an IDE or platform or language shift. Especially when that can be made already all the more difficult when you factor in multi-platform and varied capabilities of who has access to what.
-
I'm aware of that. There are of course some contrived solutions to this problem, like compiling FRED with an old MSVC version and the MFC-less game with a newer one, but is it worth it in the long term? It would be nice to see some hard numbers from profiler, to determine whether the underlying STL algorithms implementation is even a problem here. And if it is, it may be more productive to try some other approach to high level data handling. For example, vectors may be much faster than lists, despite the high insertion/deletion cost, just because they are contiguous in memory, and lists by their nature thrash the CPU cache with virtually each access to a new element.
-
The most commonly used STL containers in FSO are std::string and std::vector. For both, comparisons show that STLport is faster than the MSVC2010 implementation.
-
The_E, do you have a source for that comparison? I'd like to read up on it.
-
This (http://askldjd.wordpress.com/2010/07/24/stl-performance-comparison-round-2-vc9-vc10-stlport/) was the link google gave me.
-
I've been out of the loop for a while but I don't remember there being a very large STL usage in FSO to begin with. I would not expect there to be a huge performance gain by merely using a different STL implementation, unless there has or will be a major shift towards STL in the near future.
-
There's enough of it, and enough of it in performance-critical areas, that looking at STLport is no waste of time.
In addition, usage of vectors etc is only going to go up as time goes on.
-
Indeed. The one uncertainty with benchmarking tests is that, even though the benchmarking process may be rigorous, real-world use often doesn't behave the same way. So the best way to test out STLport is to use it under normal playing conditions. Hence the two sets of builds for comparison.
(This post is directed generally, not specifically to The E.)