Sender: jon AT blackhole DOT isdn DOT uiuc DOT edu Message-ID: <3768B177.608EC2D0@uiuc.edu> Date: Thu, 17 Jun 1999 03:27:35 -0500 From: JonMcK X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: pgcc AT delorie DOT com Subject: Re: pgcc does better, reboot, then does terrible! References: <3767970F DOT 307F679C AT uiuc DOT edu> <3768461E DOT 2AA23DED AT ameritech DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: pgcc AT delorie DOT com 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