gcc-2.95.3 vs gcc-3.0.4

gcc-2.95.3 vs gcc-3.0.4

[Justin Piszcz]

Wow, not sure if anyone here has done any benchmarks, but look at these
build times:
Kernel 2.4.17 did compile with 3.0.4, just much much slower than 2.95.3
however.

GCC 2.95.3
Boot sector 512 bytes.
Setup is 2628 bytes.
System is 899 kB
make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
287.28user 23.99system 5:15.81elapsed 98%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (514864major+684661minor)pagefaults 0swaps

GCC 3.0.4
Boot sector 512 bytes.
Setup is 2628 bytes.
System is 962 kB
warning: kernel is too big for standalone boot from floppy
make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
406.87user 28.38system 7:23.68elapsed 98%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (546562major+989237minor)pagefaults 0swaps

Re: gcc-2.95.3 vs gcc-3.0.4

[Larry McVoy]

Try 2.72, it's almost twice as fast as 2.95 for builds.  For BK, at least,
we don't see any benefit from the slower compiler, the code runs the same
either way.

On Fri, Feb 22, 2002 at 11:40:09PM -0500, Justin Piszcz wrote:
> Wow, not sure if anyone here has done any benchmarks, but look at these
> build times:
> Kernel 2.4.17 did compile with 3.0.4, just much much slower than 2.95.3
> however.
> 
> GCC 2.95.3
> Boot sector 512 bytes.
> Setup is 2628 bytes.
> System is 899 kB
> make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
> 287.28user 23.99system 5:15.81elapsed 98%CPU (0avgtext+0avgdata
> 0maxresident)k
> 0inputs+0outputs (514864major+684661minor)pagefaults 0swaps
> 
> GCC 3.0.4
> Boot sector 512 bytes.
> Setup is 2628 bytes.
> System is 962 kB
> warning: kernel is too big for standalone boot from floppy
> make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
> 406.87user 28.38system 7:23.68elapsed 98%CPU (0avgtext+0avgdata
> 0maxresident)k
> 0inputs+0outputs (546562major+989237minor)pagefaults 0swaps
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: gcc-2.95.3 vs gcc-3.0.4

[Justin Piszcz]

Ahh! Thanks for the information.

Larry McVoy wrote:

> Try 2.72, it's almost twice as fast as 2.95 for builds.  For BK, at least,
> we don't see any benefit from the slower compiler, the code runs the same
> either way.
>
> On Fri, Feb 22, 2002 at 11:40:09PM -0500, Justin Piszcz wrote:
> > Wow, not sure if anyone here has done any benchmarks, but look at these
> > build times:
> > Kernel 2.4.17 did compile with 3.0.4, just much much slower than 2.95.3
> > however.
> >
> > GCC 2.95.3
> > Boot sector 512 bytes.
> > Setup is 2628 bytes.
> > System is 899 kB
> > make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
> > 287.28user 23.99system 5:15.81elapsed 98%CPU (0avgtext+0avgdata
> > 0maxresident)k
> > 0inputs+0outputs (514864major+684661minor)pagefaults 0swaps
> >
> > GCC 3.0.4
> > Boot sector 512 bytes.
> > Setup is 2628 bytes.
> > System is 962 kB
> > warning: kernel is too big for standalone boot from floppy
> > make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
> > 406.87user 28.38system 7:23.68elapsed 98%CPU (0avgtext+0avgdata
> > 0maxresident)k
> > 0inputs+0outputs (546562major+989237minor)pagefaults 0swaps
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
> --
> ---
> Larry McVoy              lm at bitmover.com           http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: gcc-2.95.3 vs gcc-3.0.4

[Andrew Morton]

Larry McVoy wrote:
> 
> Try 2.72, it's almost twice as fast as 2.95 for builds.  For BK, at least,
> we don't see any benefit from the slower compiler, the code runs the same
> either way.
> 

Amen.

I want 2.7.2.3 back, but it was the name:value struct initialiser
bug which killed that off.  2.91.66 isn't much slower than 2.7.x,
and it's what I use.

"almost twice as fast"?  That means that 2.7.2 vs 3.x is getting
up to a 3x difference.  Does anyone know why?

[ Of course, if you can wink-in the object file from someone else,
  it's not a problem.  (tum, tee tum...) ]

-

Re: gcc-2.95.3 vs gcc-3.0.4

[Richard Gooch]

Andrew Morton writes:
> Larry McVoy wrote:
> > 
> > Try 2.72, it's almost twice as fast as 2.95 for builds.  For BK, at least,
> > we don't see any benefit from the slower compiler, the code runs the same
> > either way.
> > 
> 
> Amen.
> 
> I want 2.7.2.3 back, but it was the name:value struct initialiser
> bug which killed that off.  2.91.66 isn't much slower than 2.7.x,
> and it's what I use.
> 
> "almost twice as fast"?  That means that 2.7.2 vs 3.x is getting
> up to a 3x difference.  Does anyone know why?

I'm less concerned about compilation speed than the fact that gcc
2.95.3 generates buggy code. User-space code that used to work with
gcc 2.7.2 and egcs 1.1.2 now doesn't. Blech.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: gcc-2.95.3 vs gcc-3.0.4

[Benny Sjostrand]

>
>
>
>[ Of course, if you can wink-in the object file from someone else,
>  it's not a problem.  (tum, tee tum...) ]
>
ClearCase inspired? ( tum, tee tum ... )
That's great if you have a fast network conection, eg, using the wink-in 
feature with
CC, sometimes with slow or overloaded network it take more time wink-in 
a object
then compile it from scrash. Winking in object-files over internet may 
not always be optimal.

In case wih Linux kernel, you must wink in a object from someone that 
have exaclty the
same kernel version and configuration, that may be a complex task to 
solve ...

/Benny

Re: gcc-2.95.3 vs gcc-3.0.4

[Martin Dalecki]

Andrew Morton wrote:
> Larry McVoy wrote:
> 
>>Try 2.72, it's almost twice as fast as 2.95 for builds.  For BK, at least,
>>we don't see any benefit from the slower compiler, the code runs the same
>>either way.
>>
>>
> 
> Amen.
> 
> I want 2.7.2.3 back, but it was the name:value struct initialiser
> bug which killed that off.  2.91.66 isn't much slower than 2.7.x,
> and it's what I use.
> 
> "almost twice as fast"?  That means that 2.7.2 vs 3.x is getting
> up to a 3x difference.  Does anyone know why?

Yes. Basically the reason is a missconception what the compiler
should try to optimize in GCC.

> 
> [ Of course, if you can wink-in the object file from someone else,
>   it's not a problem.  (tum, tee tum...) ]
> 
> -
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 



-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R

Re: gcc-2.95.3 vs gcc-3.0.4

[Simon Kirby]

On Fri, Feb 22, 2002 at 09:22:18PM -0800, Andrew Morton wrote:

> Larry McVoy wrote:
> > 
> > Try 2.72, it's almost twice as fast as 2.95 for builds.  For BK, at least,
> > we don't see any benefit from the slower compiler, the code runs the same
> > either way.
> > 
> 
> Amen.
> 
> I want 2.7.2.3 back, but it was the name:value struct initialiser
> bug which killed that off.  2.91.66 isn't much slower than 2.7.x,
> and it's what I use.
> 
> "almost twice as fast"?  That means that 2.7.2 vs 3.x is getting
> up to a 3x difference.  Does anyone know why?

Me too.  Everybody says "it's the final code that matters", but a lot of
us would be more productive if the thing would just compile faster.  I've
done the same (used 2723 during development/debugging) and it helped
quite a lot.

I remember Borland Turbo Pascal's compiler... Yes, yes, but that thing
compiled insane amounts of code in split seconds on 386 hardware.

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[       sim@stormix.com       ][       sim@netnation.com        ]
[ Opinions expressed are not necessarily those of my employers. ]

Re: gcc-2.95.3 vs gcc-3.0.4

[David S. Miller]

   From: Simon Kirby <sim@netnation.com>
   Date: Mon, 25 Feb 2002 00:07:42 -0800
   
   I remember Borland Turbo Pascal's compiler... Yes, yes, but that thing
   compiled insane amounts of code in split seconds on 386 hardware.

Similarly for the earlier MIPS C compilers.

Re: gcc-2.95.3 vs gcc-3.0.4

[David Rees]

On Mon, Feb 25, 2002 at 12:07:42AM -0800, Simon Kirby wrote:
> 
> Me too.  Everybody says "it's the final code that matters", but a lot of
> us would be more productive if the thing would just compile faster.  I've
> done the same (used 2723 during development/debugging) and it helped
> quite a lot.

Well, that's true if you spend most of your time waiting for the compiler to
run, but when it takes longer to compile AND runs slower
(http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html) you lose on both counts!

Anyone have good benchmarks to run to compare raw kernel performance to see
how much using RedHat's recent (2.96) or 3.0 compilers to compile the kernel
perform vs the older compilers?

-Dave

Re: gcc-2.95.3 vs gcc-3.0.4

[Ian Castle]

On Mon, 2002-02-25 at 08:32, David Rees wrote:
> Well, that's true if you spend most of your time waiting for the compiler to
> run, but when it takes longer to compile AND runs slower
> (http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html) you lose on both counts!
> 

Doesn't this refer to floating point, and in particular, floating point
on the Athlon. So there other problems with gcc 3.x that relate to the
kernel?

Re: gcc-2.95.3 vs gcc-3.0.4

[Markus Schaber]

Hi,

Simon Kirby wrote:

> I remember Borland Turbo Pascal's compiler... Yes, yes, but that thing
> compiled insane amounts of code in split seconds on 386 hardware.

But don't forget: Pascal was designed to ease the work of compiler 
writers - at least ANSI Pascal is easy to compile using a single-pass 
recursive descent compiler. And there wasn't so much optimization.


markus
-- 
Markus Schaber - http://www.schabi.de/

Check in to another world - test a _real_ OS.

Re: gcc-2.95.3 vs gcc-3.0.4

[hugang]

On Fri, 22 Feb 2002 23:40:09 -0500
Justin Piszcz <war@starband.net> wrote:

> Wow, not sure if anyone here has done any benchmarks, but look at these
> build times:
> Kernel 2.4.17 did compile with 3.0.4, just much much slower than 2.95.3
> however.
> 
> GCC 2.95.3
> Boot sector 512 bytes.
> Setup is 2628 bytes.
> System is 899 kB
> make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
> 287.28user 23.99system 5:15.81elapsed 98%CPU (0avgtext+0avgdata
> 0maxresident)k
> 0inputs+0outputs (514864major+684661minor)pagefaults 0swaps
> 
> GCC 3.0.4
> Boot sector 512 bytes.
> Setup is 2628 bytes.
> System is 962 kB
> warning: kernel is too big for standalone boot from floppy
> make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
> 406.87user 28.38system 7:23.68elapsed 98%CPU (0avgtext+0avgdata
> 0maxresident)k
> 0inputs+0outputs (546562major+989237minor)pagefaults 0swaps
> 
Why the system size is different. Possble your use differ config.

-- 
thanks with regards!
hugang.胡刚.

***********************************
Beijing Soul Technology Co.,Ltd.
Tel:010-68425741/42/43/44
Fax:010-68425745
email:gang_hu@soul.com.cn
web:http://www.soul.com.cn
***********************************

Re: gcc-2.95.3 vs gcc-3.0.4

[Andrew Morton]

hugang wrote:
> 
> On Fri, 22 Feb 2002 23:40:09 -0500
> Justin Piszcz <war@starband.net> wrote:
> 
> ...
> > GCC 2.95.3
> ...
> > System is 899 kB
> ...
> > GCC 3.0.4
> ...
> > System is 962 kB
> ...
> >
> Why the system size is different. Possble your use differ config.

Later versions of gcc produce larger executables, due to more aggressive
alignment of code and data.  Most of this can be turned off, but the
kernel build system isn't doing that.

-

Re: gcc-2.95.3 vs gcc-3.0.4

[Paul G. Allen]

Andrew Morton wrote:
> 
> hugang wrote:
> >
> > On Fri, 22 Feb 2002 23:40:09 -0500
> > Justin Piszcz <war@starband.net> wrote:
> >
> > ...
> > > GCC 2.95.3
> > ...
> > > System is 899 kB
> > ...
> > > GCC 3.0.4
> > ...
> > > System is 962 kB
> > ...
> > >
> > Why the system size is different. Possble your use differ config.
> 

The important thing is:

Which compiler, of all of the different versions, generates the most
stable and fastest code. Compile speed and kernel size is not NEARLY as
important as performance. So, which compiler fits the bill?

PGA
-- 
Paul G. Allen
Owner, Sr. Engineer, Security Specialist
Random Logic/Dream Park
www.randomlogic.com

Re: gcc-2.95.3 vs gcc-3.0.4

[gmack]

On Sat, 23 Feb 2002, Paul G. Allen wrote:

> Which compiler, of all of the different versions, generates the most
> stable and fastest code. Compile speed and kernel size is not NEARLY as
> important as performance. So, which compiler fits the bill?
>
 
icc but only on x86 ;)



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: gcc-2.95.3 vs gcc-3.0.4

[bert hubert]

On Sat, Feb 23, 2002 at 09:27:21AM +0000, Paul G. Allen wrote:

> Which compiler, of all of the different versions, generates the most
> stable and fastest code. Compile speed and kernel size is not NEARLY as
> important as performance. So, which compiler fits the bill?

GCC 3.1, is what I'm told. 3.x has the infrastructure to do more optimizing,
but doesn't do all of it yet. 3.1 is supposed to.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

Re: gcc-2.95.3 vs gcc-3.0.4

[Luigi Genoni]

At this link:

 http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html

you can find an interesting explanation why code compiled with gcc 3.0 is
mostly slower than code compiled with gcc 2.95 on x86 CPUs (but it is
really faster on other platforms like alpha and sparc64).

basically the main reasons semm to be the scheduler algorithm and the fpu
stack handling, but I suggest to read the full study.


I would be interested to know if this apply to gcc 3.1 too.

Luigi

On Sat, 23 Feb 2002, Paul G. Allen wrote:

> Andrew Morton wrote:
> >
> > hugang wrote:
> > >
> > > On Fri, 22 Feb 2002 23:40:09 -0500
> > > Justin Piszcz <war@starband.net> wrote:
> > >
> > > ...
> > > > GCC 2.95.3
> > > ...
> > > > System is 899 kB
> > > ...
> > > > GCC 3.0.4
> > > ...
> > > > System is 962 kB
> > > ...
> > > >
> > > Why the system size is different. Possble your use differ config.
> >
>
> The important thing is:
>
> Which compiler, of all of the different versions, generates the most
> stable and fastest code. Compile speed and kernel size is not NEARLY as
> important as performance. So, which compiler fits the bill?
>
> PGA
> --
> Paul G. Allen
> Owner, Sr. Engineer, Security Specialist
> Random Logic/Dream Park
> www.randomlogic.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

ANN: syscalltrack v0.7 released

[guy keren]

syscalltrack-0.7, the 6th _alpha_ release of the linux kernel system call
tracker, is available. syscalltrack supports both versions 2.2.x and 2.4.x
of the linux kernel. The current release contains some major enhancements,
and various bug fixes and code cleanups. See details below.

* What is syscalltrack?

syscalltrack is a linux kernel module and supporting user space
environment which allow interception, logging and possibly taking
action upon system calls that match user defined criteria
(syscalltrack can be thought of as a sophisticated, system wide
strace).

* Where can i get it?

Information on syscalltrack is available on the project's homepage:
http://syscalltrack.sourceforge.net, and in the project's file
release.

You can download the source directly from:
http://prdownloads.sourceforge.net/syscalltrack/syscalltrack-0.70.tar.gz

* Call for developers:

The syscalltrack project is looking for developers, both for kernel
space and user space. If you want to join in on the fun, get in touch
with us on the 'syscalltrack-hackers' mailing list
(http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).

* License and NO Warrany

'syscalltrack' is Free Software, licensed under the GNU General Public
License (GPL) version 2. The 'sct_ctrl_lib' library is licensed under
the GNU Lesser General Public License (LGPL).

'syscalltrack' is in _alpha_ stages and comes with NO warranty.
If it breaks something, you get to keep all of the pieces.
You have been warned (TM).

Happy hacking and tracking!

=======================================================================

Major new features for 0.7
--------------------------

* Support for dynamic-cast of 'struct' syscall parameters when filtering
  based on them, and for logging. See the relevant section in
  doc/sct_config_manual.html for how to use this feature. Mostly useful now
  for checking struct parameters in socket calls, so now its possible
  to check if a client prorgam tries to connect to a given port or IP address,
  etc.

* Support for 'fail syscall' actions - allows you to specify that a matching
  syscall invocation will prematurely return a given error code (or '0')
  before the system call is actually performed. Handle with care, as failing
  the wrong syscall invocations might render your system unuseable. Good
  usage example: TODO

* Support for convenience-macros in rule config files. Currently supported
  macros include:

    - ipaddr("127.0.0.1") -> translates an IP address to an unsigned long
			     in network byte-order.
    - htons(7) -> host to network byte-order for 'short' numbers.
    - usernametoid("root") -> translates user name to UID.
    - groupnametoid("wheel") -> translates group name to GID.

* Experimental Device-driver control support - the syscalltrack kernel module
  can now be controlled via a device-file interface - specify "-c device_file"
  when running 'sct_config' to use it. The interface is currently
  functionaly-equivalent to the existing 'sysctl' interface - but it will be
  enhanced in the future to support logging via a device-file interface,
  getting rule list via the device-file interface, etc.

* Support for 'log_format' definition per rule, to override the global
  'log_format'.

* Initial correctness-testing script added. Currently only runs 2 tests -
  will become more functional on the next release.

* Support for new system calls - waitpid, close and creat.

major bug fixes for version 0.7:

* Fixes for white-space parsing in 'sct_config'.

* Fix small memory leak when deserializing 'log' actions

* Fix bug in the kernel module that would leave dangling function pointers
  in case a user cleared only the 'before' function pointer. This bug
  wasn't triggered, since sct_config always erased _all_ rules, causing this
  code path to remain yet unused.

=======================================================================

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

Re: gcc-2.95.3 vs gcc-3.0.4

[Jakub Jelinek]

On Mon, Feb 25, 2002 at 01:07:42AM +0100, Luigi Genoni wrote:
> At this link:
> 
>  http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html
> 
> you can find an interesting explanation why code compiled with gcc 3.0 is
> mostly slower than code compiled with gcc 2.95 on x86 CPUs (but it is
> really faster on other platforms like alpha and sparc64).
> 
> basically the main reasons semm to be the scheduler algorithm and the fpu
> stack handling, but I suggest to read the full study.
> 
> 
> I would be interested to know if this apply to gcc 3.1 too.

Well, concerning reg-stack, you can completely get away without it in 3.1 
by using -mfpmath=sse if you are targeting Pentium 3,4 or Athlon 4,xp,mp
(for float math, for higher precision only for Pentium 4).

	Jakub

Re: gcc-2.95.3 vs gcc-3.0.4

[Luigi Genoni]

On Mon, 25 Feb 2002, Jakub Jelinek wrote:

> On Mon, Feb 25, 2002 at 01:07:42AM +0100, Luigi Genoni wrote:
> > At this link:
> >
> >  http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html
> >
> > you can find an interesting explanation why code compiled with gcc 3.0 is
> > mostly slower than code compiled with gcc 2.95 on x86 CPUs (but it is
> > really faster on other platforms like alpha and sparc64).
> >
> > basically the main reasons semm to be the scheduler algorithm and the fpu
> > stack handling, but I suggest to read the full study.
> >
> >
> > I would be interested to know if this apply to gcc 3.1 too.
>
> Well, concerning reg-stack, you can completely get away without it in 3.1
> by using -mfpmath=sse if you are targeting Pentium 3,4 or Athlon 4,xp,mp
> (for float math, for higher precision only for Pentium 4).

Yes, but the lot of users (like me) who are still using Athlon TB, 1330 or
1400 Mhz, and who do not have any reason to upgrade to MP since the
performance gain is not really considerable, they cannot use sse instructions.
So, what could they do? should they stay with gcc 2.95?

Re: gcc-2.95.3 vs gcc-3.0.4

[Jakub Jelinek]

On Mon, Feb 25, 2002 at 10:46:52AM +0100, Luigi Genoni wrote:
> > > At this link:
> > >
> > >  http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html
> > >
> > > you can find an interesting explanation why code compiled with gcc 3.0 is
> > > mostly slower than code compiled with gcc 2.95 on x86 CPUs (but it is
> > > really faster on other platforms like alpha and sparc64).
> > >
> > > basically the main reasons semm to be the scheduler algorithm and the fpu
> > > stack handling, but I suggest to read the full study.
> > >
> > >
> > > I would be interested to know if this apply to gcc 3.1 too.
> >
> > Well, concerning reg-stack, you can completely get away without it in 3.1
> > by using -mfpmath=sse if you are targeting Pentium 3,4 or Athlon 4,xp,mp
> > (for float math, for higher precision only for Pentium 4).
> 
> Yes, but the lot of users (like me) who are still using Athlon TB, 1330 or
> 1400 Mhz, and who do not have any reason to upgrade to MP since the
> performance gain is not really considerable, they cannot use sse instructions.
> So, what could they do? should they stay with gcc 2.95?

Linux kernel doesn't use floating point math at all, so this is irrelevant
on lkml, moving to an more appropriate list...

	Jakub

Re: gcc-2.95.3 vs gcc-3.0.4

[Jan Hubicka]

> On Mon, Feb 25, 2002 at 10:46:52AM +0100, Luigi Genoni wrote:
> > > > At this link:
> > > >
> > > >  http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html
> > > >
> > > > you can find an interesting explanation why code compiled with gcc 3.0 is
> > > > mostly slower than code compiled with gcc 2.95 on x86 CPUs (but it is
> > > > really faster on other platforms like alpha and sparc64).
> > > >
> > > > basically the main reasons semm to be the scheduler algorithm and the fpu
> > > > stack handling, but I suggest to read the full study.

You should understand that this is mostly the special case.
Atlas loop is hand tuned to compile well with gcc 2.x.x and 3.x.x
prduces worse code on it.   

I've tracked down and fixed problem that made Atlas loop to run out
of registers in 3.1.x so it works well again. (It is not that dificult
to prepare corresponding patch for 3.0.x in case there is interest)

There was nothing wrong with the scheduler and the analysis on page
are somewhat missleading. Real problem was that gcc "forgotten" about
posibility of using memory operand in certain cases of commutative
i387 fp instructions requiring one additional register. (this happent as
result of two independent major change sin the compiler)
This register is not available in the loop curefully written for 8 registers
and causes the performance drop.

In specFP perofmrance, gcc 3.0.1 is about 4% better on specfp according to
the results at http://www.suse.de/~aj/SPEC
Honza
> > > >
> > > >
> > > > I would be interested to know if this apply to gcc 3.1 too.
> > >
> > > Well, concerning reg-stack, you can completely get away without it in 3.1
> > > by using -mfpmath=sse if you are targeting Pentium 3,4 or Athlon 4,xp,mp
> > > (for float math, for higher precision only for Pentium 4).
> > 
> > Yes, but the lot of users (like me) who are still using Athlon TB, 1330 or
> > 1400 Mhz, and who do not have any reason to upgrade to MP since the
> > performance gain is not really considerable, they cannot use sse instructions.
> > So, what could they do? should they stay with gcc 2.95?
> 
> Linux kernel doesn't use floating point math at all, so this is irrelevant
> on lkml, moving to an more appropriate list...
> 
> 	Jakub

Re: gcc-2.95.3 vs gcc-3.0.4

[Juan Quintela]

>>>>> "justin" == Justin Piszcz <war@starband.net> writes:

justin> Wow, not sure if anyone here has done any benchmarks, but look at these
justin> build times:
justin> Kernel 2.4.17 did compile with 3.0.4, just much much slower than 2.95.3
justin> however.

justin> GCC 2.95.3
justin> Boot sector 512 bytes.
justin> Setup is 2628 bytes.
justin> System is 899 kB
justin> make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
justin> 287.28user 23.99system 5:15.81elapsed 98%CPU (0avgtext+0avgdata
justin> 0maxresident)k
justin> 0inputs+0outputs (514864major+684661minor)pagefaults 0swaps

justin> GCC 3.0.4
justin> Boot sector 512 bytes.
justin> Setup is 2628 bytes.
justin> System is 962 kB
justin> warning: kernel is too big for standalone boot from floppy
justin> make[1]: Leaving directory `/usr/src/linux-2.4.17/arch/i386/boot'
justin> 406.87user 28.38system 7:23.68elapsed 98%CPU (0avgtext+0avgdata
justin> 0maxresident)k
justin> 0inputs+0outputs (546562major+989237minor)pagefaults 0swaps

Hi, here the times chaned with the lastest 3.0.4, this is the first
3.0 compiler that is faster than 2.96 here.  Compilation of a mdk
kernel (i.e. a kernel with everthing as modules).

(I compiled twice with both compilers & there are not variances).

2.96
2018.76user 159.29system 18:13.20elapsed 199%CPU (0avgtext+0avgdata 0maxresident
)k
0inputs+0outputs (4007797major+8765072minor)pagefaults 0swaps

gcc-3.0.4
1797.23user 133.06system 16:07.98elapsed 199%CPU (0avgtext+0avgdata 0maxresident
)k
0inputs+0outputs (3569637major+8775450minor)pagefaults 0swaps

And the size differences are not as big as they used to be:

root$ ls -l vmlinux*
-rwxr-xr-x    1 root     root      3177771 Feb 24 18:06 vmlinux*
-rwxr-xr-x    1 root     root      3206468 Feb 24 17:47 vmlinux-3.0.4*
root$ size vmlinux*
   text    data     bss     dec     hex filename
2253010  301448  423008 2977466  2d6eba vmlinux
2294630  304924  423008 3022562  2e1ee2 vmlinux-3.0.4

Until now, gcc-3.0 binaryes tend to be quite bigger than gcc-2.96.

root$ rpm -qa | grep gcc | grep -v cpp
gcc-2.96-0.76mdk
libgcc3.0-3.0.4-1mdk
gcc3.0-3.0.4-1mdk


Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy