Author Topic: go_faster_differently  (Read 2871 times)

0 Members and 1 Guest are viewing this topic.

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
go_faster_differently
I've heard good things about the STLport 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

Builds using STLport

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.

 

Offline wolf

  • 25
Re: go_faster_differently
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.

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Minecraft
    • Steam
    • Twitter
    • ModDB Feature
Re: go_faster_differently
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.
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 

Offline wolf

  • 25
Re: go_faster_differently
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.

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: go_faster_differently
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.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Echelon9

  • Moderator
  • 210
Re: go_faster_differently
The_E, do you have a source for that comparison? I'd like to read up on it.

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: go_faster_differently
This was the link google gave me.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Bobboau

  • Just a MODern kinda guy
    Just MODerately cool
    And MODest too
  • 213
Re: go_faster_differently
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.
Bobboau, bringing you products that work... in theory
learn to use PCS
creator of the ProXimus Procedural Texture and Effect Generator
My latest build of PCS2, get it while it's hot!
PCS 2.0.3


DEUTERONOMY 22:11
Thou shalt not wear a garment of diverse sorts, [as] of woollen and linen together

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: go_faster_differently
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.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
Re: go_faster_differently
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.)