On May 9, 6:41=A0pm, "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
> <kumar...@[EMAIL PROTECTED]
> wrote in message
>
>
news:4780a4b0-8034-4a20-9058-8d53c89bfdd4@[EMAIL PROTECTED]
>
>
>
> > hello:
>
> > I recently compiled a numerically intensive c project under cygwin gcc
> > 3.4.4 and microsoft visual c. The platform is intel T2400 1.83 ghz
> > dual core lap top.
>
> > the numerical stuff is both floating point and integer intensive
>
> > The gcc optimized (-O3) vs non optimized improved the performance 30 %
>
> > visual c optimized (standard , check 'release; under visual c 2005)
> > vs non optimized ('build') was a whopping 8x performance gain
>
> > but the most surprising thing was visual c optimized was 2x
> > performance over gcc optimized.
>
> likely reason:
> MS focuses a lot more on specific optimizations, and tweaking
performance
> for specific targets;
> gcc, however, targets many targets, and tends to use far more generic
code=
> generation (they try more to leverage fancy general purpose
optimizations,=
> rather than arch-specific tweaks for various special cases).
>
> in any case, gcc tends to, fairly often, produce fairly silly code (even
> with optimizations), and, sadly, even with a very braindead
lower-compiler=
> design (a hacked over stack machine), and optimizations focusing more on
> "common special cases", it is not too hard to match or somewhat exceed
gcc=
's
> performance...
>
> IMO, the 'O' options may well be Obfuscate rather than Optimize...
>
> actually, one of the better ways at optimizing, would be likely to
impleme=
nt
> a kind of abstract combinatorial tester, which would basically search
the
> space of possible optimizations and look for the ones with the lowest
> simulated cost. sadly though, this will not work so well in the face of
> usage patterns, which require actually using the code (the general
option
> could treat a very common case like an uncommon case, ...).
>
> in something like a VM, it could be possible to use a kind of genetic
> evolver for adapting functions (initially, it compiles functions
> generically, and any functions it detects are using a significant
****tion =
of
> the time, it starts mutating in an attempt to improve the general
> performance). later, if/when a "final" version is desired, it uses the
> versions of the functions found to be most effective.
>
> note that this would likely be confined to the realms of low-level
> optimization, with what are typically the biggest time wasters (general
> algorithmic issues), being beyond the scope of such a tool...
>
> the simplest approach, however (and the one I currently use in my
compiler=
),
> is to basically just test the compiler, and any obvious issues in the
outp=
ut
> (silly code), are ones I focus on fixing.
>
> the compiler machinery itself in my case, as this level, is little more
th=
an
> just a very large and elaborate mass of decision trees (no fancy
transform=
s
> or general optimizer machinery, more just operations dispatched through
a
> maze of function calls).
>
> this approach seems to work good enough IME...
>
> > is anybody else seeing the same thing. if this is true microsoft c
> > compiler is in a different league altogether
>
> that, or, most of us are not that concerned with raw performance (vs
havin=
g
> a compiler we are not obligated to pay for...).
>
> none the less, MS has at least a decent compiler in these regards...
>
> > i was not successful so far compiling under mingw. will it make dent ?
> > 2x is hard to overcome
>
> well, with gcc, it is hard to do much better...
>
> as noted, MSVC and Intel are good options...
thanx all of you for responding. I was totally unprepared for such a
vast performance difference (2x msvc vs gcc) and my code is not at all
special(no UI, complicated cl***** etc). it simply does lots of
floating point array(mainly through fft) and normal integer
operations
I used -O3 flag and in my case so far it seems to be better than O2.
msvc by default uses their own O2.
I cannot believe such a blatant difference will go unnoticed for long
in our type of situation the intel compiler is not an option.
primarily because we have a standaradized dll plug in architecture
and so (if windoz do msvc) applies.
|
