470,833 Members | 1,987 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,833 developers. It's quick & easy.

MS vs Intel C++ compilers for Windows

Ozo
What would be the C++ compiler producing the fastest code for Windows
XP Pro (32-bit)? I have to choose between these two:

- Visual C++ 2005 compiler
- Intel C++ Compiler 9.0 for Windows

My previous experience with older versions of these two compilers told
me that Intel code was running faster than MS code. But now that I am
about to upgrade, I would lile to pick the one producing the fastest
code (things may have changed!).

I thought that some of you could have seen benchmarks with some large
C++ projects and so could shed some light on this.

Thanks,

Ozo.

Mar 15 '06 #1
17 3955
Oz*@whoever.com wrote :
But now that I am
about to upgrade, I would lile to pick the one producing the fastest
code (things may have changed!).


Is that really the most important thing ?

Mar 15 '06 #2
Ozo
loufoque a écrit :
Oz*@whoever.com wrote :
But now that I am
about to upgrade, I would lile to pick the one producing the fastest
code (things may have changed!).


Is that really the most important thing ?


Yes it is. I am working on a real-time application where each
milisecond is important. I prefer to gain 1-2 ms by simply upgrading
the compiler (and then use this extra time to do more) instead of
re-designing large parts of the application hoping to get the same
result. In real-time systems, the total number of available
miliseconds to do actual processing is limited; If a better compiler
let you do more in the same time, it is more than welcome.

Ozo.

Mar 16 '06 #3
Oz*@whoever.com wrote:
What would be the C++ compiler producing the fastest code for Windows
XP Pro (32-bit)? I have to choose between these two:

- Visual C++ 2005 compiler
- Intel C++ Compiler 9.0 for Windows

My previous experience with older versions of these two compilers told
me that Intel code was running faster than MS code. But now that I am
about to upgrade, I would lile to pick the one producing the fastest
code (things may have changed!).

I thought that some of you could have seen benchmarks with some large
C++ projects and so could shed some light on this.

Thanks,

Ozo.


I don't know of any performance benchmarks...

Have you considered the (free) GNU CGG System ('gcc' for C,
and 'g++' for C++)?

Larry
Mar 16 '06 #4

<Oz*@whoever.com> wrote in message
news:11*********************@j33g2000cwa.googlegro ups.com...
| What would be the C++ compiler producing the fastest code for Windows
| XP Pro (32-bit)? I have to choose between these two:
|
| - Visual C++ 2005 compiler
| - Intel C++ Compiler 9.0 for Windows
|
| My previous experience with older versions of these two compilers told
| me that Intel code was running faster than MS code. But now that I am
| about to upgrade, I would lile to pick the one producing the fastest
| code (things may have changed!).
|
| I thought that some of you could have seen benchmarks with some large
| C++ projects and so could shed some light on this.
|
| Thanks,
|
| Ozo.
|

[OT]
Does the Intel compiler run faster when the processor is not an Intel
processor? definitely not.

Here is the hick: anything built on the NT platform, including XP, will gain
a significant increase in speed when using a RISC cpu. NT loves RISC (thats
old news). Not that i want to shake your foundation, but in light of that
fact you may want to reconsider your priorities.

And incidentally, fast code is obtained by disciplined, sound coding
practices. Such code can improve a program's performance by levels of
magnitude instead of the meager 5% or so that you are considering as
relevent.

Mar 16 '06 #5
Oz*@whoever.com wrote:
What would be the C++ compiler producing the fastest code for Windows
XP Pro (32-bit)? I have to choose between these two:

- Visual C++ 2005 compiler
- Intel C++ Compiler 9.0 for Windows

My previous experience with older versions of these two compilers told
me that Intel code was running faster than MS code. But now that I am
about to upgrade, I would lile to pick the one producing the fastest
code (things may have changed!).

I thought that some of you could have seen benchmarks with some large
C++ projects and so could shed some light on this.

Thanks,

Ozo.


Well, use both if you can, that way you can compare them with your own
program. All benchmarks you can find depends on a certain context so it
is best that the context is your program.

Ben
Mar 16 '06 #6
On 15 Mar 2006 19:24:58 -0800, Oz*@whoever.com wrote:
loufoque a écrit :
Oz*@whoever.com wrote :
> But now that I am
> about to upgrade, I would lile to pick the one producing the fastest
> code (things may have changed!).


Is that really the most important thing ?


Yes it is. I am working on a real-time application where each
milisecond is important. I prefer to gain 1-2 ms by simply upgrading
the compiler (and then use this extra time to do more) instead of
re-designing large parts of the application hoping to get the same
result. In real-time systems, the total number of available
miliseconds to do actual processing is limited; If a better compiler
let you do more in the same time, it is more than welcome.


XP is not a real-time OS, you can only hope to gain near real-time
response on such a platform, so you're simply founded on wishful
thinking. Even if your wishes come true and gain a few more
milliseconds, it will be intermittent and won't be sustained.

Mar 16 '06 #7
I don't know of any performance benchmarks...

Have you considered the (free) GNU CGG System ('gcc' for C,
and 'g++' for C++)?

VC7.1 C++ compiler optimizes code much better and faster than GCC from
my experience.
Mar 16 '06 #8
Have you considered trying gcc 4.1 - the latest release includes, as
far as my experience of it goes, better optimisations than the previous
versions (especially the 3.x branch)

Mar 16 '06 #9
Gernot Frisch wrote:
I don't know of any performance benchmarks...

Have you considered the (free) GNU CGG System ('gcc' for C,
and 'g++' for C++)?

VC7.1 C++ compiler optimizes code much better and faster than GCC from
my experience.


That's not been my experience on Linux (: (: (:

Sorry, I couldn't resist...

Larry
Mar 17 '06 #10
Ozo

Peter_Julian wrote:
<Oz*@whoever.com> wrote in message
news:11*********************@j33g2000cwa.googlegro ups.com...
| What would be the C++ compiler producing the fastest code for Windows
| XP Pro (32-bit)? I have to choose between these two:
|
| - Visual C++ 2005 compiler
| - Intel C++ Compiler 9.0 for Windows
|
| My previous experience with older versions of these two compilers told
| me that Intel code was running faster than MS code. But now that I am
| about to upgrade, I would lile to pick the one producing the fastest
| code (things may have changed!).
|
| I thought that some of you could have seen benchmarks with some large
| C++ projects and so could shed some light on this.
|
| Thanks,
|
| Ozo.
|

[OT]
Does the Intel compiler run faster when the processor is not an Intel
processor? definitely not.

Here is the hick: anything built on the NT platform, including XP, will gain
a significant increase in speed when using a RISC cpu. NT loves RISC (thats
old news). Not that i want to shake your foundation, but in light of that
fact you may want to reconsider your priorities.

And incidentally, fast code is obtained by disciplined, sound coding
practices. Such code can improve a program's performance by levels of
magnitude instead of the meager 5% or so that you are considering as
relevent.


In some cases, there are things that you can not change. In my case,
the PC platform we use is already deployed at many customer sites, it
is Intel-based, and it can not change. Also, hundred thousands lines
of legacy code can not simply be re-visited in the hope of performance
gains: this is simply not a viable option. I know that different
compilers can produce significant differences in performance. Of
course, I can try them all and find by myself, but I was naively hoping
that such benchmark numbers would already exist somewhere.

Ozo.

Mar 17 '06 #11
Peter_Julian :
Here is the hick: anything built on the NT platform, including XP,
will gain a significant increase in speed when using a RISC cpu.


On which risc platform has XP been released ?

--
John Deuf
Mar 18 '06 #12

"John Deuf" <no****@dontuseit.com> wrote in message
news:Xn***********************@212.27.42.203...
| Peter_Julian :
|
| > Here is the hick: anything built on the NT platform, including XP,
| > will gain a significant increase in speed when using a RISC cpu.
|
| On which risc platform has XP been released ?
|
| --
| John Deuf

On any platform that supports emulating an intel cpu, like AMD, for
example.

Mar 22 '06 #13
Peter_Julian wrote:
"John Deuf" <no****@dontuseit.com> wrote in message
news:Xn***********************@212.27.42.203...
| Peter_Julian :
|
| > Here is the hick: anything built on the NT platform, including XP,
| > will gain a significant increase in speed when using a RISC cpu.
|
| On which risc platform has XP been released ?
|
As far as I know, none. I believe a Win2K beta ran on the Alpha, and
NT ran on the PowerPC. It is amusing that, what with their microkernel
architecture, they seem to find it difficult to run on anything but
x86, meanwhile Linux (a monolithic kernel) runs on all manner of chips,
from handhelds and up.
| --
| John Deuf

On any platform that supports emulating an intel cpu, like AMD, for
example.


Emulation? What? Think slow....

AMD natively supports the x86 instruction set. In fact, the AMD64
instruction set, which is an extension of the x86 set, is now
implemented by Intel.

Besides, Microsoft would do everything possible to compile their code
so it runs as fast as possible on x86. Obviously it's hard to make
comparisons with Windows, but I believe there are some simple
comparisons between Linux running on Intel vs. PowerPCs.

http://en.wikipedia.org/wiki/AMD64

And finally, these chips themselves have now adopted RISC like
architectures, so there isn't as huge a difference between them
anymore:

http://en.wikipedia.org/wiki/X86

"Current x86 processors employ a few "extra" decoding steps to (during
execution) split (most) x86 instructions into smaller pieces (called
"micro-ops") which are then readily executed by a RISC-like
micro-architecture."

Mar 22 '06 #14
>
In some cases, there are things that you can not change. In my case,
You can't. Not that others couldn't.
the PC platform we use is already deployed at many customer sites, it
is Intel-based, and it can not change.
Just for an example, Apple is PPC based and is switching to Intel. If
they can do it...
Also, hundred thousands lines
of legacy code can not simply be re-visited in the hope of performance
gains: this is simply not a viable option. I know that different
Totally viable option. Refactoring. Optimization. That's probably
what your competitors are doing.
compilers can produce significant differences in performance. Of
course, I can try them all and find by myself, but I was naively hoping
that such benchmark numbers would already exist somewhere.
Couple things, in addition to the excellent advice you've already
discounted (so be it).
(1) Sure you could find some benchmarks. There are all sorts of bench
marks - but that's all they are - they don't ensure that for your
particular app, it will be any improvement.

http://www.research.att.com/~orost/b...lus/paper.html

(2) Don't assume that swapping out the compiler will fix everything.
In fact, your app might break, or run differently - so you're in the
same situation as if you'd refactored the code, i.e. you'll need to
verify *everything* still works. Ozo.


Mar 24 '06 #15
Ozo

Michael O'Keeffe a écrit :
the PC platform we use is already deployed at many customer sites, it
is Intel-based, and it can not change.
Just for an example, Apple is PPC based and is switching to Intel. If
they can do it...


I can not ask all my customers to simply replace their hardware because
my new software version is running too slow to be realtime anmore.
Also, hundred thousands lines
of legacy code can not simply be re-visited in the hope of performance
gains: this is simply not a viable option. I know that different


Totally viable option. Refactoring. Optimization. That's probably
what your competitors are doing.


Ok, maybe a "viable" option, but probably not the cheapest one.
(1) Sure you could find some benchmarks. There are all sorts of bench
marks - but that's all they are - they don't ensure that for your
particular app, it will be any improvement.

http://www.research.att.com/~orost/b...lus/paper.html
I am looking for benchmarks "results" that compare the performance of
Visual C++ 2005 compiler verus Intel C++ Compiler 9.0 for Windows. I
don't need some C++ benchmark application : my own application is a
much better benchmark for my own needs.
(2) Don't assume that swapping out the compiler will fix everything.
In fact, your app might break, or run differently - so you're in the
same situation as if you'd refactored the code, i.e. you'll need to
verify *everything* still works.


You're right. But Intel market their Window compiler under that
assumption (compatibility woth MSVC++), so I have to assume that only
mnimal work would be require, i.e. much less than having someone
re-writing legacy and proven code.

Regards,

Ozo.

Mar 25 '06 #16

<Oz*@whoever.com> wrote in message news:11**********************@i39g2000cwa.googlegr oups.com...

[snip]
I am looking for benchmarks "results" that compare the performance of
Visual C++ 2005 compiler verus Intel C++ Compiler 9.0 for Windows.
[snip]

Comparative Performance: Intel C++ 8.0, Visual C++ 7.0 and other compilers.
Source code can be used to test Comparative Performance for any realeses of compilers.

Computing Very Long Fibonacci Numbers
http://article.gmane.org/gmane.comp.....perfometer/37

Copying Files
http://article.gmane.org/gmane.comp....perfometer/378
--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn
Apr 15 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Leor Zolman | last post: by
1 post views Thread by Peter Forthmann | last post: by
4 posts views Thread by merlevo | last post: by
3 posts views Thread by nikaggel | last post: by
5 posts views Thread by jhc0033 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.