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
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 [email protected]
> 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
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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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...) ]
-
On Fri, 22 Feb 2002 23:40:09 -0500
Justin Piszcz <[email protected]> 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:[email protected]
web:http://www.soul.com.cn
***********************************
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: [email protected]
Current: [email protected]
hugang wrote:
>
> On Fri, 22 Feb 2002 23:40:09 -0500
> Justin Piszcz <[email protected]> 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.
-
Andrew Morton wrote:
>
> hugang wrote:
> >
> > On Fri, 22 Feb 2002 23:40:09 -0500
> > Justin Piszcz <[email protected]> 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
http://www.randomlogic.com
>
>
>
>[ 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
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 [email protected]
> 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
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
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
[email protected]
<>< As a computer I find your faith in technology amusing.
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 <[email protected]> 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
> http://www.randomlogic.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
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. ]
[ [email protected] ][ [email protected] ]
[ Opinions expressed are not necessarily those of my employers. ]
From: Simon Kirby <[email protected]>
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.
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
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?
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?
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.
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
> 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
>>>>> "justin" == Justin Piszcz <[email protected]> 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