Re: compiler optimization? something else?

At 20:34 08.03.00, Sean Harding wrote:

I posted this on comp.os.linux.powerpc without any response. Perhaps someone
here can address it.

Is anyone working on optimizing the compiler for PPC? It seems like it could
use a little work. Maybe that's not actually the problem here, but it's the
first thing that springs to mind.

I recently was playing with encoding mp3s using LAME on several
systems. LAME 3.63beta compiles easily out of the box, but it is

                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But what compiler options did it use on with your compile? I downloaded it
myself and it seems to default to a simple -O, which is a rather
non-optimal choice. Try editing the Makefile and play with combinations of
these options:

-O2, -O3, -funroll-loops, -funroll-all-loops, -ffast-math (dunno if this
one has an effect on PPC at all), -finline-functions, -mcpu=604, -mcpu=750

Do that and come back with a table listing your encoding times for the
different switch combinations.

quite a bit slower than is seeems it should be. For one sample file, the
encoding took 32 minutes on my PPC 604/150. The same file, encoded with the
same options, took 6 minutes on my PII 366 laptop. I get similar speeds on
Tru64 alpha systems, HP-UX pa-risc systems and Solaris sparc systems.
Obviously there are differences in speed for these systems based on the CPU,
etc. But they all perform in line with what I would expect to see. It's
just ppc that's way slower.

Well, if you set the compiler options to suboptimal values, this is what
you would expect. I think I saw hand-tuned compiler options for all
platforms you listed, just not for Linux/PPC+gcc, which usually means
nobody did care til now. Remember Linux is a collaborative effort and if
you care about something being done/implemented/optimized/etc you usually
have to do it yourself or maybe kick the right people :-).

The system is not i/o bound during the encode, and there were no other
CPU-intensive processes running at the time. If this were an isolated case,
I wouldn't worry too much about it. But it seems like most CPU-intensive
tasks are slower than they should be.

My system is pretty generic LinuxPPC 1999 right now. Here's what I have:

juliet ~
26% uname -a
Linux juliet 2.2.13 #1 Fri Nov 12 23:01:37 PST 1999 ppc unknown

juliet ~
27% gcc --version
egcs-2.91.66

Upgrade to gcc-2.95.2, <ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/ppc/>.
Though I don't believe this will give you a really big improvement in code
optimization, it is a big step forward in compiler correctness on PPC.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 9 Mar 2000, Franz Sirl wrote:

But what compiler options did it use on with your compile? I downloaded it
myself and it seems to default to a simple -O, which is a rather
non-optimal choice. Try editing the Makefile and play with combinations of
these options:

-O2, -O3, -funroll-loops, -funroll-all-loops, -ffast-math (dunno if this
one has an effect on PPC at all), -finline-functions, -mcpu=604, -mcpu=750

-ffast_math has some effects in the generic part of the compiler
(simplifying some expressions and constant folding) since even some
obvious mathematical relationships do not hold with IEEE floating point.
Main reasons are the existence of NaNs and the distinction between
positive and negative zeroes. (x+0 and x-0 can't be simplified, x==x may
not be true...).  -ffast-math will also replace divisions by constants
with multiplies, which may be slightly less precise but is always
significantly faster (especially on a 604).

If you don't have a 601 -fgfxopt might also help since it will generate
fsel instructions for min/max/conditional moves. fsel is unfortunately not
implemented on 601 so you can't set gfxopt for distributions.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

juliet ~
27% gcc --version
egcs-2.91.66

Upgrade to gcc-2.95.2, <ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/ppc/>.
Though I don't believe this will give you a really big improvement in code
optimization, it is a big step forward in compiler correctness on PPC.

I don't see any speed improvement from egcs-1.1.12 to gcc 2.95.2. Various
tests done with lame and mpg123 show than 2.95.2 produces code only 0.5%
faster or so. Executable size is 10-15% smaller.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/