This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g77 performance on ALPHA
- To: N8TM at aol dot com
- Subject: Re: g77 performance on ALPHA
- From: Martin Kahlert <martin dot kahlert at provi dot de>
- Date: Sun, 29 Aug 1999 11:28:01 +0200
- Cc: egcs at egcs dot cygnus dot com
- References: <91e2f005.24f95ce8@aol.com>
- Reply-To: martin dot kahlert at provi dot de
Quoting N8TM@aol.com (N8TM@aol.com):
> In a message dated 8/28/99 3:28:13 AM PST, martin.kahlert@provi.de writes:
>
> > So, how could g77 be improved most easily?
> > Is it a problem with the Haifa-scheduler? It seems to me that gcc
> > can't take that much advantage from unrolling like Compaq's compiler.
> As your code shows, gcc/g77 schedulers, either the old one or Haifa, don't do
> much for pipelined processors which lack out-of-order execution or shadow
> register re-mapping. They do fairly well on several out-of-order processors.
> For example, my g77 code speeded up more with a change from R10000 to R12000
> processor than the MipsPro code did, and I'm getting generally 80% of the
> performance from g77 which I get from MipsPro f90 with a great deal of array
> syntax optimization.
O.k. this rises the dumb question (sorry, i never hacked inside gcc):
Why use such a complicate thing like the Haifa scheduler at all when
we rely on out of order cpus?
Why not just emit instructions as soon as they arise? (Perhaps after
a good register allocator) If i imagine correctly, lcc does something like
that.
> The trend in some of the processor families has been to make use of OOO etc.
> to enable fast execution of simple object code. As the gnu compilers are
> required to perform well on such processors, including those which have a
> small set of registers directly available to the program, I suppose it's
> unlikely that good performance will be obtained where such specialized code
> generation is needed. The Pentium II processor runs quite well with the
> -mpentiumpro option, which is the one which generates code compatible with
> processors back to 486, but without skewing scheduling toward the older
> models. This is particularly true of code which doesn't spend much time in
> tight little loops.
Most long running progs will spend a lot of time in quite small loops.
But you are perfectly right, gcc-2.95.1 is quite good on PPro machines.
I get only about 10% by using a commercial compiler, here.
> A trend which goes along with the development of processor families is that
> the compilers are tuned for the model which has the largest customer base
> paying current support contracts and buying compilers. For example, the
> current MipsPro compilers have lost performance on the last Mips models which
> lack OOO, even though the architecture switches are retained. g77 never got
> even 40% of the speed of the chip vendor's compilers on those older models,
> and I'm sure that the vendors weren't thinking of g77 when they developed
> better hardware which depends less on code tuning.
>
> If the resources were available, I would rather see effort spent on compiler
> transformations such as outer unrolling than on targeting specific CPU models.
I use gcc/g77 because of its wide range of supported architectures.
So good code on all architectures is a desireable thing for me, too.
Thanks for your long reply,
Martin.
--
Your mouse has moved, Windows must be restarted for changes
to take affect - restart now?