Board index » cppbuilder » MS Vis Tool kit 2003

MS Vis Tool kit 2003


2004-04-23 10:10:00 AM
cppbuilder28
Any comments on this.....
msdn.microsoft.com/visualc/vctoolkit2003/
 
 

Re:MS Vis Tool kit 2003

I just downloaded MS Visual Toolkit 2003 to try building an app that takes many
minutes that is entirely CPU bound. Okay, I I had MSVC v6 compiler version 12.00.8168
to compare to it. This latest VC Toolkit cl.exe reports itself as 13.10.3052 by
comparison. I have a P4 2.2 Ghz on Windows 2000 with latest service pak and security
fixes.
Here's the twist: running the exact same make file I'm getting the new version
running much longer than the version produced with MSVC. Whereas my MSVC version does
a certain stage of processing in 18 seconds the VC Toolkit 2003 does it in 30
seconds. A bigger stage of processing is 249 seconds versus 429.
Okay, so I see that the makefile (not mine) doesn't do any optimization. So I added
/G7 (Athlon and P4) and /GL (whole program optimization). This slows the 18/30
seconds stage to an even worse 32 seconds and the 249/429 to an even worse 437.
So then I added /Ox to the compiler flags which is supposed to turn on all sorts of
optimizations. That did not help at all. Slightly worse results at 32 and 439 seconds.
So I'm getting:
MSVC 18 249
New MS unoptimized 30 429
New MS /G7 /GL 32 429
New MS /G7 /GL /Ot 32 439
One noteworthy thing about this app is that it does a huge number of heap operations.
I wonder if the new compiler is slower doing heap operations. Like, maybe it is using
the multithreaded library and therefore doing a mutex operation every time it
allocates and frees on the heap. But I'm not telling it which library to link to for
the basic C++ stuff.
Okay, I once more deleted all the objs and exe and added /ML (link to LIBC.LIB which
I think is the non-threaded equivalent of /MT LIBCMT.LIB) to the invocation of the CL
to do the link stage. Rebuilding did not speed things up at all.
MS says on their site at that link that this is an optimizing compiler. Well, not for
me. Anyone have a better result with it?
Colin B Maharaj wrote:
Quote
Any comments on this.....

msdn.microsoft.com/visualc/vctoolkit2003/
 

Re:MS Vis Tool kit 2003

Quote
Okay, I once more deleted all the objs and exe and added /ML (link to LIBC.LIB which
I think is the non-threaded equivalent of /MT LIBCMT.LIB) to the invocation of the CL
to do the link stage. Rebuilding did not speed things up at all.
The single threaded runtime library is significantly faster (regarding heap operations) than the
multithreaded one, which is optimized for multithreaded programs.
So i suppose that the difference in speed isnīt caused by the heap allocations,
VC2003 also produces (normally) faster code than VC6.
Is the code compilable with BCB6 ? Or with the Intel compiler
(if available - currently one of the best optimizing compilers)
to have a speed comparison with other compilers ?
Andre
 

{smallsort}

Re:MS Vis Tool kit 2003

Andre,
I'm currently trying to build it with Intel v7.1. I've hit a couple of problems that
I'm trying to work thru. I'll post back when I know.
I expect BCB v6 to be slower than MSVC v6 or Intel v7.1. I really want to make it
build it with Intel. Once I've succeeded there I may try BCB next.
Andre Kaufmann wrote:
Quote
Is the code compilable with BCB6 ? Or with the Intel compiler
(if available - currently one of the best optimizing compilers)
to have a speed comparison with other compilers ?

Andre


 

Re:MS Vis Tool kit 2003

Randall Parker < XXXX@XXXXX.COM >wrote:
Quote
[...]
MS says on their site at that link that this is an optimizing compiler. Well, not for
me. Anyone have a better result with it?
I haven't done any code speed comparisons,
but I have followed a few discussions on
the MS newsgroups. IIRC, most of the issues
were solved with setting different compiler
switches.
Of course, having little or no CPU-bound
code, I can't be very helpfull in this
regard. However, I would suppose posting
there you could get some help. Having a
repro case at hand (or beeing able to send
a preprocessed file if asked for) usually
helps a lot.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 

Re:MS Vis Tool kit 2003

Hi!
I downloaded the kit too and remade some DLL's in VS for image
processing, using Ox and G7 optimizations. What I did not expect, was
that the code was even a bit slower (3%) than the BCB6 code. I thought
VS was much better than Borland.
Ben
Randall Parker wrote:
Quote
I just downloaded MS Visual Toolkit 2003 to try building an app that
SNIP
results at 32 and 439 seconds.

So I'm getting:

MSVC 18 249
New MS unoptimized 30 429
New MS /G7 /GL 32 429
New MS /G7 /GL /Ot 32 439

Did you comare it with BCB? I also saw that unoptimized the code was
slightly faster than with the Ox option.
Quote

Colin B Maharaj wrote:

>Any comments on this.....
>
>msdn.microsoft.com/visualc/vctoolkit2003/
Ben
 

Re:MS Vis Tool kit 2003

It used to be when it was less compliant, but I guess now that it is more
compliant, it is slower :(
- a bit like BCB compiler.
Perhaps Borland weren't so bad after all :)
Rgds Pete
"Ben" < XXXX@XXXXX.COM >wrote in message
Quote
Hi!
I thought VS was much better than Borland.
 

Re:MS Vis Tool kit 2003

I don't buy standards compliance as an excuse. I tried the Intel v7.1 compiler.
Here's my new table:
MSVC 18 249
New MS unoptimized 30 429
New MS /G7 /GL 32 429
New MS /G7 /GL /Ot 32 439
Intel 7.1 /G7 /Ot 17 226
Note that the /GL flag caused Intel to have an internal error with an exception.
This program I'm testing does a huge amount of heap operations. I'm wondering whether
that is where the bottleneck is coming from.
Pete Fraser wrote:
Quote
It used to be when it was less compliant, but I guess now that it is more
compliant, it is slower :(
- a bit like BCB compiler.
Perhaps Borland weren't so bad after all :)
Rgds Pete

"Ben" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>Hi!
>I thought VS was much better than Borland.



 

Re:MS Vis Tool kit 2003

"Randall Parker" < XXXX@XXXXX.COM >wrote in message news:40893910$ XXXX@XXXXX.COM ...
<...snip>
Quote
This program I'm testing does a huge amount of heap operations. I'm wondering whether
that is where the bottleneck is coming from.
Hi Randall,
one point to mention: /G7 optimization will generate P4 optimized code which
might run slower on other processors.
The heap operations of the multithreaded library are definitively slower than the single threaded one.
I wondered why they are so much slower, since the operations of another compiler compared to
didnīt have a significant different performance of the multithreaded library compared to its single threaded one.
I did some speed measures with multiple consecutive running threads doing permanently heap allocations.
(Side note: test system was a P4 3GHz with ! Hyperthreading !)
The timing scaled linearly with the number of threads.
E.g.:
1 Thread = 20 ms
2 Threads = 40 ms
3 Threads = 80 ms
While with the other compiler i got the following timing results:
1 Thread = 18 ms
2 Threads = 400 ms
3 Threads = 1,2 minutes
Obviously the other compiler run permanently into a critical section waiting for the other threads.
The speed decrease (up to factor 2) you measured, is the one you (can) get if you switch to the multithreaded
runtime library.
So i wonder why your results didnīt change or got even worse, when you use the single threaded library
instead of the multithreaded one.
I donīt expect it to help that much, but the command line for a full single threaded optimization with exception handling
would be:
/Ox /Og /Oi /Ot /Oy /G7 /GF /EHsc /arch:SSE2 /ML
Andre
 

Re:MS Vis Tool kit 2003

Please take this conversation to the MS groups. This has
nothing to do with BCB.
 

Re:MS Vis Tool kit 2003

Randall Parker < XXXX@XXXXX.COM >writes:
Quote
I don't buy standards compliance as an excuse.
Agreed. C++ standards compliance has little to do with executable code
performance, except perhaps for some penalty when exceptions are involved.
[snip]
Quote
This program I'm testing does a huge amount of heap operations. I'm
wondering whether that is where the bottleneck is coming from.
If your program does "huge amounts of heap operations", you the C/C++
runtime, not the compiler. My experience is that Borland's memory
handling routines are ~2x faster for certain allocation/deallocation
patterns. Maybe Borland's memory handling is faster on most cases.
OTOH, either Intel or GCC throws Borland out of the water producing
optimized code. When template-metaprogramming and other high level
stuff is involved, the difference is dramatic.
--
Oscar
 

Re:MS Vis Tool kit 2003

Jeff Overcash (TeamB) wrote:
Quote

Please take this conversation to the MS groups. This has
nothing to do with BCB.
Or at the very least to the BCBX newsgroups, as this toolkit can be used
with BCBX.
--
Vesty.
 

Re:MS Vis Tool kit 2003

"Adam Versteegen" < XXXX@XXXXX.COM >wrote:
Quote
Jeff Overcash (TeamB) wrote:

>
>Please take this conversation to the MS groups. This has
>nothing to do with BCB.


Or at the very least to the BCBX newsgroups, as this toolkit can be used
with BCBX.

And this is being discussed there ()or was a day or two ago).
Quote
--
Vesty.


 

Re:MS Vis Tool kit 2003

Hi Jeff
I'm sorry, but I not pleased too to argue about Micro$oft in this group.
But Borland is aging and we have to look around for another compiler.
Unfortunately this is the only place where you find others having the
same problems.
Ben
I won't send a followup
Jeff Overcash (TeamB) wrote:
Quote
Please take this conversation to the MS groups. This has
nothing to do with BCB.

 

Re:MS Vis Tool kit 2003

Good to know about Borland's memory handling speed. I'm going to try Borland next
just to see whether that factor matters for this app.
Oscar Fuentes wrote:
Quote
If your program does "huge amounts of heap operations", you the C/C++
runtime, not the compiler. My experience is that Borland's memory
handling routines are ~2x faster for certain allocation/deallocation
patterns. Maybe Borland's memory handling is faster on most cases.

OTOH, either Intel or GCC throws Borland out of the water producing
optimized code. When template-metaprogramming and other high level
stuff is involved, the difference is dramatic.