Mail Archives: pgcc/1999/06/17/11:10:40
paulr wrote:
>
> 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.
As I said here, including or not including -pg has no effect on the
situation. It's still very slow now. The BINARY IS ACTUALLY different with
the above compile option before and after. Before is much faster than
now(after).
I know what -ffast-math does, I've read the man page. All it does is not
check for errors such as a negative sqrt.
> > 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.
Nono. I didn't compile binutils with -pg. binutils is NOT my program, and
size isn't the issue, it's speed. I installed binutils thought the normal:
./configure ; make ; make install (as root).
> 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.....
The reason I was using -pg is to profile the code, to see how fast it is.
It works quite well, showing that my perf is terrible now, which it is.
>
> FWIW, I'm a newbie on this list. Feel free to correct/comment/criticize.
> Please remain gentlemanly ;-)
Well, I appreciate your attempt at help, but try again if you have any other
ideas.
>
> >
> > ------------
> >
> > 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???
no. binutils is just something I installed that may have caused the
problem. The code/binary I speak of is MINE, my personal physics code I
mentioned at the beginning.
> > 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???
no, see above.
> >
> > 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.....
10X for gprof?? My personal code is only about 10% larger than before.
> 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....
Not the issue here. Before my code was fast, now it's slow and I don't know
why. The binaries compiling the exact same code with the exact same options
is different. WHY?
Thanks,
Jon
- Raw text -