Mail Archives: pgcc/1999/06/16/20:52:44
JonMcK wrote:
>
> I'm confused as heck. Here's some info:
>
> [jon AT blackhole Exe]$ gcc -v
> Reading specs from
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
> gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
>
> -------
>
> Here's my confusion. I'm programming some physics stuff. I've been
> optimizing my code and thought I'd try out pgcc. Compiled it myself with
> bootstrap and low and behold all the profile times decreased on my
> P2-333/Redhat6.0 system. Happy days are here!
>
> Here's my CFLAGS:
> CFLAGS = -Wall -mpentium -mcpu=pentiumpro -march=pentiumpro -O4 -pipe
> -malign-loops=2 -malign-jumps=2 -malign-functions=2 --fast-math -pg
^^^^^
and see the info page regarding -ffast-math. It could have some unintended
consequences, depending on what your code is doing....
>
> -pg or not the problem below is the same.
>
> I read about binutils2.9.1 being needed for mmx, etc. so I decided to
> compile->install that. I wasn't sure what version I already had, turns out
> I think I had 2.9.1. Oddly, my compiled binutils files are huge! I didn't
> realize "larger" meant 10X larger! Anyways, this isn't the problem.
>
> [jon AT blackhole Exe]$ ls -al /usr/bin/gprofold
> -rwxr-xr-x 1 root root 95668 Apr 5 20:08 /usr/bin/gprofold
> [jon AT blackhole Exe]$ ls -al /usr/local/bin/gprof
> -rwxr-xr-x 1 root root 1045169 Jun 16 03:07 /usr/local/bin/gprof
^^^^^^^^^
I wouldn't be surprised if compiling with -pg would do this. If the pgcc
command line conventions are similar to egcs, pg would comile against both
a profiling and debugging library. You'll have all the symbol tables loaded
in your resulting executable, along with code profiling data. That could
certainly explain why the code is MUCH bigger.
Bet the size of the "gprof" you build will shrink a lot if you do
strip --strip-debug /usr/local/bin/gprof
Probably be a very good idea *not* to use -pg on PRODUCTION code. Use
-pg on development/debug code, and remove -pg when you're ready to
go to production.....
FWIW, I'm a newbie on this list. Feel free to correct/comment/criticize.
Please remain gentlemanly ;-)
>
> ------------
>
> I then decided to recompile my kernel(2.2.5-22). That went fine, modules
> installed, etc. I reboot and to my UTTER HORROR after checking some times
> on my code it's all ALOT slower, by about 30%. Essentially losing 2 days
> worth of optimizing!!
>
> Ok, I thought. Must be the kernel and/or modules. So I revert back to my
> previous kernel/modules(I always have a backup). TO MY HORROR it's still
> slow as heck!
>
> I looked at all my options, trying to see if I just happened to change
> something, then I remember a directory where I compiled the old good
> version. I run that binary, and it's FAST, just like it was before! I then
^^^^^^^^^^^^^^^
Which binary? Part of binutils???
> move that in a safe place and recompile with the EXACT same settings as that
> FAST one was compiled. I run it, and it's SLOW! I compare the binaries and
> they are DIFFERENT!
********
>
> My questions:
>
> 1) WHAT THE HECK did I do? Could binutils do this?
Did you compile binutils with -pg???
>
> 2) The binaries are just 50k each, but the FAST one is a bit larger. WHY?
> What changed? HELP!
The faster binary may be a bit larger because of the extra pentium
micro-instruction scheduler code.....
It may be worth taking a look at Intel's developer site, and look at the
stuff about micro-instructions/pipelines and scheduling of same. There's
also a good "executive summary" on www.microway.com called "Pentium White Paper"
by Steve Fried (sp?) that might also be useful....
Regards,
Paul
--
*******************************************
Paul Reich Motorola, Inc.
reichp AT ameritech DOT net Staff Engineer
#include <Motorola/std_disclaimer.h>
"A CPU Cycle is a Terrible Thing to waste."
*******************************************
- Raw text -