Re: VC++2005 executables much slower than VC++6????
<plahey@alumni.caltech.edu> wrote in message
news:1159392671.763038.324660@h48g2000cwc.googlegroups.com...
I really question microsoft's decision on this one. One of the main
themes of C++ is that "you don't pay for what you don't use" and one of
the goals of STL was that it have as little over head as possible
(that's why there is no bounds checking on the indices of vectors, for
instance). Having a "debug mode" for the standard library is extremely
valuable but leaving (even some) checking on _by default_ in release
mode (and only being able to turn those off by non-standard means) is
highly questionable. Especially when it makes a C++ program
substantially slower than a nearly identical C# and Java programs
(which force you to always leave the checking on).
Not blaming you of course :-)
Believe me, you're not the first to question the logic :)
On the other hand, consider that computers are 1000x faster than they were
just a few years ago - in most cases, far faster than required for the task
at hand (and no, games don't constitute "most cases" - they're a very
special breed with their own special needs). Programmers who've "not paid
for" what they "didn't use" have managed to write 1000's of buffer overrun
bugs and other vulnerabilities, so maybe it IS time to change the defaults
to have the "seatbelts" on unless you specifically decide to turn them off.
Another thing that changed in VC 2005 - there's no longer a single threaded
CRT. For artificial benchmarks like this, that too can lead to surprising
results. If you're not doing so already, try building your VC6 and G++ code
using the multi-threaded runtimes.
Also, the VC++ standard library is far more standard conformant than VC6 (I
don't know about G++ since there are so many versions with such a wide
variety of conformance that it's impossible to speculate). I can't say for
sure, but it's possible that correctness fixes in the VC++ 2005 standard
library also have an adverse effect on your benchmark.
-cd