Re: Pgcc in Deb
Drake Diedrich wrote:
>
> 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.
I remember reading something about gcc having an option that would
insert
code to profile all the branches in a programs and save that data to
disk.
Then, next time you compiled it would read this data in and use it to
decide how to arrange the code within a function optimally.
Unfortunatly I can't find any reference to it right now.
The next level up is to analyse the call structure of a whole program
and rearrange all the functions so that functions that call eachother
tend to be near one another, so when they are paged in they get paged
in together. The effect is for rarely used functions to end up lumped
together near the end of the executable and reducing the in memory
working set size.
Apparently SGI has a tool that does this and someone was writing a
GPL'd version called Grope. Unfortunatly I can't find anything about
that either.
Anyway, I think these types of optimisations would be more effective and
more processor independant.
--
Martijn van Oosterhout <kleptog@cupid.suninternet.com>
Reply to: