Re: Pgcc in Deb

[Drake Diedrich <Drake.Diedrich@anu.edu.au>]

On Fri, Apr 07, 2000 at 04:41:51AM +0300, Eray Ozkural wrote:
> 
> Still, I am sure there's a lot of room for improvement. For instance, there
> are some results which I don't usually disclose. A state-of-the art
> graph partitioning tool developed at my dept. performs much better on i686
> when compiled with Microsoft's VC than on the gcc. Don't worry, I turned on all

> The developer of that package is not here, and I'm not sure where I put those
> benchmarks, but still I was bashed as a proud programmer who only used gcc.
> Yet, the VC is a terrible compiler, especially for C++... But it surely has
> a better x86 backend


   It may not be an architecture-specific problem.  Search for
interprocedural analysis (IPA).  gcc doesn't, VC may.  Small subroutines can
be transparently inlined or otherwise optimized across function boundaries
by postponing compilation until the linking stage.  -IPA under the Irix
compilers improved povray performance ~2X for me.  I'm not sure if anyone is
working on it for gcc (it sounds difficult), but people have been talking
about it (Dave McAllister- SGI head tech for one).
   If you can move all of the source code into one file and make all
subroutines static you might coerce gcc to optimize across the boundaries
the way an IPA compiler would.  IPA may be the reason VC is so far behind
the ANSI C++ standard, since it gets into all aspects of the compiler and
makes changes more difficult.

   Kai (i386), Portland Group (i386), Compaq C/C++ (alpha) might be worth
investigating if you can't work around the gcc IPA problems and don't mind
using a nonfree compiler.  That's not an option for Debian though.