Re: EGCS optimizations
Alex Zepeda wrote: On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message As far as I know, pgcc is different from egcs. I had pgcc, it did *significantly* better code than gcc at the time (about 1 to 2 years before), especially in floating point code, but it was buggy. I have egcs-1.2 (on a current-3.0) and I am rather disappointed with the code performance. With standard code without floating point calculations it does a bit worse than old gcc-2.7.x. In floating point (as in Mesa, ..) it is awful. It generates much slower code, than gcc-2.7.x. I am using an old Linpack benchmark (Calculate n linear equations) and I can get best perfomance usually with gcc-2.7.x using -O (*not* -O2!!). The same seems to be true with egcs, but more so. Egcs with x86-prozessors work best with -O, don't use more (-marchxxx does nothing significant). I understand there are reasons to switch to egcs (exceptions, C++ enhancements,..) but I hope they will do something for egcs' code performance. (Does code size really matter that much. Sure, it accumulates, but...). -- Helmut F. Wirth Email: hfwi...@teleweb.at To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
On Tue, 6 Apr 1999, David O'Brien wrote: Well what would be the chances of getting the pgcc patches committed? I'm quite interested in doing this, BUT only after the dust has settled on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC patches aren't available yet. jdp and I have another round of bootstraping to fix our current less-than-optimal exception handling. I want to wait a week or so until putting the changes into the tree. It's important to note that PGCC is NOWHERE NEAR production quality, last time I tried it, and not proven at all. I express no animosity toward PGCC itself, but unless it's been proven, I'd strongly oppose anything like this. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
In the last episode (Apr 05), Alex Zepeda said: Have you tried anything beyond -O2? There is only -O3, which is just like -O2 except that it tries to inline all functions. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. When I tested this last year, -O3 on egcs produced a 10-15% slowdown for things like 'gzip'. OTOH, gcc's -O3 produced slightly faster code (as I recall). I /do/ however see noticeable (10-20%) speed improvements using -O2 -mpentium -march=pentium compared to -O2 -mno-486 on gcc. Kris - The Feynman problem-solving algorithm: 1. Write down the problem 2. Think real hard 3. Write down the solution To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. Incorrect. gdb 4.18 supports frame-pointerless debugging, and gcc will generate the proper DWARF2 info to support it. I've done it before many times. In fact, two of the test programs in the testsuite i use to test my BeOS port of GDB are compiled specifically *with* -fomit-frame-pointer to amke sure the DWARF2 reading and unwinding is working properly. I don't know if it's in the 1.1 branch, i know it's been in the HEAD branch for a while. on the gdb side, i remember seeing it sometime after february, and i've used it since march. Also, if you guys want to play the EGCS benchmark game, let me point you to the *surprise* BENCHMARKS, a link to which can be found on the egcs homepage (as well as test suite results). They are very well organized. Go submit some results so people have more to compare against. Also, -mpentiumpro will actually usually generate WORSE code for a pentium pro. -mpentium and -march=pentium do better at it. I would use -O2 with the 1.1 branch, and -O99 with the head branch. As the benchmarks note, -O6 *IS* faster than -O3 which *IS* faster than -O2. They usually use the higher -O levels to test out experimental optimizations. Another useful optimization is -funroll-loops, which does what you think it does. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Matthew Dillon wrote: :Totally informally, I replaced libc (compiled with -O2) with one compiled :with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit :slower (GNU make took longer to traverse directories and egcs took a bit :longer to run). : : Which leads me to believe that using -Os might be beneficial. : :Have you tried anything beyond -O2? : :- alex There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. I don't have oppurtunity to use CURRENT, but on 3.1-RELEASE and 2.2.8 -fomit-frame-pointer applied to kernel compilation leads to system crash. If you want to reproduce this, compile kernel with -O -fomit-frame-pointer, reboot, and try, for example, to build kernel with make -j 16 ;) -Matt Matthew Dillon dil...@backplane.com -- Pavel Narozhniy nic-hdl: PN395-RIPE http://www.sumy.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Hi, At 2:15 am -0700 6/4/99, Daniel Berlin wrote: Also, -mpentiumpro will actually usually generate WORSE code for a pentium pro. -mpentium and -march=pentium do better at it. OK, but according to man cc: NAME gcc, g++ - GNU project C and C++ Compiler (egcs-1.1.2) [...] -mpentium Synonym for -mcpu=pentium [...] Specifying -march=cpu type implies -mcpu=cpu type. If this is right, then -mpentium is redundant in the presence of -march=pentium. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
I always use both (because it's in my darn makefiles :P), but that sounds correct to me. If it said -mpentium implied -march=pentium, i'd say it's lying. most of the -mwhatever architecture alone are worthless, it's the -march's that matter (note i say most to mean of the 4 architectures i've played with -m and -march on). On Tue, 6 Apr 1999, Bob Bishop wrote: Hi, At 2:15 am -0700 6/4/99, Daniel Berlin wrote: Also, -mpentiumpro will actually usually generate WORSE code for a pentium pro. -mpentium and -march=pentium do better at it. OK, but according to man cc: NAME gcc, g++ - GNU project C and C++ Compiler (egcs-1.1.2) [...] -mpentium Synonym for -mcpu=pentium [...] Specifying -march=cpu type implies -mcpu=cpu type. If this is right, then -mpentium is redundant in the presence of -march=pentium. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: EGCS optimizations
-Original Message- From: Matthew Dillon [mailto:dil...@apollo.backplane.com] Sent: 06 April 1999 05:58 To: curr...@freebsd.org Subject: EGCS optimizations Compiling up /usr/src/usr.sbin with egcs and libc compiled with: -O2 160 seconds -O2 -march=pentiumpro 162 seconds -Os 161 seconds Which leads me to believe that using -Os might be beneficial. If I'm reading that right you timed how long it took to build /usr/src/usr.sbin using egcs and libc compiled with the above optimisations? I doubt that that sort of benchmark is going to say an awful lot about the performance of the optimisation levels since compiling /usr/sr/usr.sbin is going to be affected by disk i/o performance far more than it would be by cpu performance. The relative speed differences of the different egcs/libc binaries is probably smoothed out by the i/o affects which is why the times look so similar. Something that is more cpu bound would be a better benchmark for comparing the optimisation options. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
:I doubt that that sort of benchmark is going to say an awful lot about the :performance of the optimisation levels since compiling /usr/sr/usr.sbin is :going to be affected by disk i/o performance far more than it would be by :cpu performance. The relative speed differences of the different egcs/libc :binaries is probably smoothed out by the i/o affects which is why the times :look so similar. : :Something that is more cpu bound would be a better benchmark for comparing :the optimisation options. : : :Paul. That test was 100% cpu bound. There was no ( significant ) I/O. I ran it a few times to build the cache before timing it. It's no big deal, really. I think the EGCS bandwagon is going to continue to move forward and PGCS runs on top of it, so moving to EGCS puts FreeBSD in a better position in the long term. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
In message 199904062001.naa10...@apollo.backplane.com, Matthew Dillon writes: That test was 100% cpu bound. There was no ( significant ) I/O. I ran it a few times to build the cache before timing it. What is the stddev on your measurements ? a delta-T 1 second need a very tight stddev to be significant. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Alex Zepeda wrote: On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. pgcc isn't the same as egcs the current -mpentiumpro and -mpentiumarch stuff were taken from pgcc and ported back to egcs but i believe that pgcc has gone way beyond what it was when that happened. rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:it a few times to build the cache before timing it. : :What is the stddev on your measurements ? : :a delta-T 1 second need a very tight stddev to be significant. The timing was +/- 0.5 second ( I ran the test four times ). But, remember, this is not comparing against GCC. This was simply comparing various EGCC optimization features. stddev on ~160 seconds +/- 0.5s is basically 0, so it is not a useful measurement beyond noting that it is near 0. I would love to see a comparison against GCC. I blew away my GCC :-( and do not want to spend time reinstalling it. :-- :Poul-Henning Kamp FreeBSD coreteam member :p...@freebsd.org Real hackers run -current on their laptop. :FreeBSD -- It will take a long time before progress goes too far! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:What is the stddev on your measurements ? : :a delta-T 1 second need a very tight stddev to be significant. I would say that a 1% increase or decrease in performance is not significant, so stddev is not significant either. There are too many other factors ( such as running a single program suite - EGCC, that does one task - compiling, instead of many different suites ). -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
On Tue, 6 Apr 1999, Matthew Dillon wrote: It's no big deal, really. I think the EGCS bandwagon is going to continue to move forward and PGCS runs on top of it, so moving to EGCS puts FreeBSD in a better position in the long term. Well what would be the chances of getting the pgcc patches committed? It seems like this wouldn't have a negative impact on other non x86 hardware, but might be a win for us stuck with Pentiums or PIIs. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
Well what would be the chances of getting the pgcc patches committed? I'm quite interested in doing this, BUT only after the dust has settled on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC patches aren't available yet. jdp and I have another round of bootstraping to fix our current less-than-optimal exception handling. I want to wait a week or so until putting the changes into the tree. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
On Tue, 6 Apr 1999, David O'Brien wrote: Well what would be the chances of getting the pgcc patches committed? I'm quite interested in doing this, BUT only after the dust has settled on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC patches aren't available yet. Cool!! jdp and I have another round of bootstraping to fix our current less-than-optimal exception handling. I want to wait a week or so until putting the changes into the tree. Well, congrats on the reasonably smooth job so far. The only other thing I'd have on my wish list is the ability to not build the gcc related bits (so I could say drop in TenDRA) by adding -DNO_GCC or something. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Hmm. interesting. My test kernel under GCC was considerably smaller then my test kernel under EGCS, even with -Os. textdata bss dec hex filename 1287575 95512 122972 1506059 16fb0b kernel.gcc -O2 1326304 111628 125708 1563640 17dbf8 kernel.egcs -Os -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: My conclusion: Don't bother with -mpentiumpro or -march=pentiumpro. Not only do they not result in better performance, -march=pentiumpro will not run on a K6-2. I dunno about a K6-3. -mcpu does not change the assembly output at all. -march=cpu does change the assembly output, but does not appear to result in any noticeable improvement in performance over not using -m at all. Totally informally, I replaced libc (compiled with -O2) with one compiled with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit slower (GNU make took longer to traverse directories and egcs took a bit longer to run). Which leads me to believe that using -Os might be beneficial. Have you tried anything beyond -O2? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:Totally informally, I replaced libc (compiled with -O2) with one compiled :with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit :slower (GNU make took longer to traverse directories and egcs took a bit :longer to run). : : Which leads me to believe that using -Os might be beneficial. : :Have you tried anything beyond -O2? : :- alex There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:On Mon, 5 Apr 1999, Matthew Dillon wrote: : : There is nothing beyond -O2. Well, there's -O3, which tries to : inline static functions, but that typically isn't beneficial because : it really bloats up the code and subroutine calls on intel cpus are : very fast. : :Really? : :The pgcc web page (goof.com/pcg) lead me to believe that there were a few :more optimizations turned on by -O5 -O6.. : :- alex pgcc != egcs. PGcc is a patchset on top of egcs and I suppose they might have added additinoal -O options, but egcs itself does not go beyond -O3. The PGcc faq indicates that they are slowly folding their stuff into egcs. Hopefully they've fixed the bugs :-). I have not tried compiling a kernel under pgcc but now that FreeBSD has moved to EGCS, it may actually work! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
