Re: GCC speed (was [PATCH] Isapnp warning)

Re: GCC speed (was [PATCH] Isapnp warning)

[John Bradford]

> If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much
> faster than the later versions.  I used to yank newer versions of gcc
> off systems and put 2.7.2 on, I think it was close to 2x faster at
> compilation and made no difference on BK performance.

Out of interest, have you tried compiling BK with tcc?

John.

Re: GCC speed (was [PATCH] Isapnp warning)

[Larry McVoy]

On Mon, Jun 23, 2003 at 08:40:52AM +0100, John Bradford wrote:
> > If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much
> > faster than the later versions.  I used to yank newer versions of gcc
> > off systems and put 2.7.2 on, I think it was close to 2x faster at
> > compilation and made no difference on BK performance.
> 
> Out of interest, have you tried compiling BK with tcc?

Nope.  I can if you want but I'll bet it doesn't support all our platforms.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: GCC speed (was [PATCH] Isapnp warning)

[Christoph Hellwig]

On Thu, Jul 17, 2003 at 06:23:50AM -0400, Jakub Jelinek wrote:
> They handle some C99 initializers, but definitely not what the
> standard mandates.

Umm, it does handle the common case of C99 struct initializers used
in the kernel.  It might not handle some cases that aren't used by
the kernel which make you right from the language lawyer perspective
but which is rather irrelevant for this discussion.

Re: GCC speed (was [PATCH] Isapnp warning)

[Jakub Jelinek]

On Thu, Jul 17, 2003 at 11:18:05AM +0100, Christoph Hellwig wrote:
> On Fri, Jan 04, 2002 at 12:32:05PM +0100, Pavel Machek wrote:
> > Perhaps someone schould create 2.7.3 with long long bugs fixed
> > and with c99 initializers?
> 
> 2.7 does have C99 initializers.

No, neither egcs 1.1.x nor gcc 2.95*.
They handle some C99 initializers, but definitely not what the
standard mandates.

	Jakub

Re: GCC speed (was [PATCH] Isapnp warning)

[Christoph Hellwig]

On Fri, Jan 04, 2002 at 12:32:05PM +0100, Pavel Machek wrote:
> Perhaps someone schould create 2.7.3 with long long bugs fixed
> and with c99 initializers?

2.7 does have C99 initializers.

Re: GCC speed (was [PATCH] Isapnp warning)

[Larry McVoy]

If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much 
faster than the later versions.  I used to yank newer versions of gcc 
off systems and put 2.7.2 on, I think it was close to 2x faster at 
compilation and made no difference on BK performance.

On Sun, Jun 22, 2003 at 10:32:51AM -0700, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> >
> > As for compilation speed, yes, that sucks.  I doubt there's any rational 
> >  reason for it, but I also agree with the idea that correctness and binary 
> >  code performance should come first, then the compilation speed issue should 
> >  be addressed.
> 
> No.  Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces.  These are surely the
> most important things by which a toolchain's usefulness should be judged.
> 
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
> 
> I'm happy allowing those thousands of people who do not compile kernels all
> the time to shake out any 3.2/3.3 compilation problems.
> 
> 
> Compilation inefficiency is the most serious thing wrong with gcc.
> 
> -
> 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 speed (was [PATCH] Isapnp warning)

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 22 June 2003 22:07, John Bradford wrote:
> > No, the build system is OK.  And ccache nicely fixes up any mistakes
> > which the build system makes, and distcc speeds things up by 2x to 3x.
> >
> > None of that gets around the fact that code needs to be tested with
> > various combinations of CONFIG_SMP, CONFIG_PREEMPT, different
> > subarchitectures, spinlock debugging, etc, etc.  If the compiler is slow
> > people don't bother doing this and the code breaks.
> >
> > Cause and effect.
>
> Are the benchmarks that show gcc 3.3 to be much slower at compile time
> being done with a natively compiled gcc 3.3?  I.E. gcc 3.3 compiled
> with itself?
>
> When I upgraded a few machines from 2.95.3 to 3.2.3, I noticed that
> the last of the three compiles, (I.E. a gcc-3.2.3 compiled gcc-3.2.3
> compiling the gcc-3.2.3 source), was noticably quicker than the first
> two, to the extent that it was easily mesaurable by a wall clock.
>
> I am just wondering whether there gcc-3.X binaries in use that were
> compiled with gcc-2.95.3, that are swaying benchmarks in favour of
> 2.95.3 compiled with itself.
>
> I haven't benchmarked gcc-2.95.3 compiled with gcc-3.2.3, though.

The preferred build command for gcc is
$ make bootstrap
AFAIK that compiles the compiler in three stages.
stage1 => normal with currently installed compiler
stage2 => with stage1 compiler
stage3 => I don't know. Either with stage1 or stage2.

So if you built it with bootstrap it's impossible to have
bad or good performance, just because it was built this
this or that compiler.

Please correct me if I'm wrong. :)

> John.

- -- 
Regards Michael Büsch
http://www.8ung.at/tuxsoft
 22:23:42 up  1:25,  1 user,  load average: 1.01, 1.02, 0.97

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+9hEfoxoigfggmSgRAgMSAJ9VI4qcNZZSrvvNv+yAsAehBPAc8wCeJmc2
7C5KMOzhgBYO3ccFSO9oikA=
=UHkb
-----END PGP SIGNATURE-----

Re: GCC speed (was [PATCH] Isapnp warning)

[John Bradford]

> No, the build system is OK.  And ccache nicely fixes up any mistakes which
> the build system makes, and distcc speeds things up by 2x to 3x.
>
> None of that gets around the fact that code needs to be tested with various
> combinations of CONFIG_SMP, CONFIG_PREEMPT, different subarchitectures,
> spinlock debugging, etc, etc.  If the compiler is slow people don't bother
> doing this and the code breaks.
>
> Cause and effect.

Are the benchmarks that show gcc 3.3 to be much slower at compile time
being done with a natively compiled gcc 3.3?  I.E. gcc 3.3 compiled
with itself?

When I upgraded a few machines from 2.95.3 to 3.2.3, I noticed that
the last of the three compiles, (I.E. a gcc-3.2.3 compiled gcc-3.2.3
compiling the gcc-3.2.3 source), was noticably quicker than the first
two, to the extent that it was easily mesaurable by a wall clock.

I am just wondering whether there gcc-3.X binaries in use that were
compiled with gcc-2.95.3, that are swaying benchmarks in favour of
2.95.3 compiled with itself.

I haven't benchmarked gcc-2.95.3 compiled with gcc-3.2.3, though.

John.

Re: GCC speed (was [PATCH] Isapnp warning)

[Adrian Bunk]

On Sun, Jun 22, 2003 at 06:58:04PM +0000, Henning P. Schmiedehausen wrote:
> Andrew Morton <akpm@digeo.com> writes:
> 
> Your problem is not the compiler but the build tool / system which
> forces you to recompile all of your kernel if you change only small
> parts.

That's not true in 2.5, the 2.5 build system only recompiles files that 
have to be recompiled.

But if you edit an often used header file many fils have to be 
recompiled.

> 	Regards
> 		Henning

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: GCC speed (was [PATCH] Isapnp warning)

[Henning Schmiedehausen]

Hi,

well to me that sounds like a perfect job for a continous build tool. If
a human must wait on this, then yes, you're right.

	Regards
		Henning


On Sun, 2003-06-22 at 21:13, Andrew Morton wrote:
> "Henning P. Schmiedehausen" <hps@intermeta.de> wrote:
> >
> >  Your problem is not the compiler but the build tool / system which
> >  forces you to recompile all of your kernel if you change only small
> >  parts.
> 
> No, the build system is OK.  And ccache nicely fixes up any mistakes which
> the build system makes, and distcc speeds things up by 2x to 3x.
> 
> None of that gets around the fact that code needs to be tested with various
> combinations of CONFIG_SMP, CONFIG_PREEMPT, different subarchitectures,
> spinlock debugging, etc, etc.  If the compiler is slow people don't bother
> doing this and the code breaks.
> 
> Cause and effect.
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: GCC speed (was [PATCH] Isapnp warning)

[Andrew Morton]

"Henning P. Schmiedehausen" <hps@intermeta.de> wrote:
>
>  Your problem is not the compiler but the build tool / system which
>  forces you to recompile all of your kernel if you change only small
>  parts.

No, the build system is OK.  And ccache nicely fixes up any mistakes which
the build system makes, and distcc speeds things up by 2x to 3x.

None of that gets around the fact that code needs to be tested with various
combinations of CONFIG_SMP, CONFIG_PREEMPT, different subarchitectures,
spinlock debugging, etc, etc.  If the compiler is slow people don't bother
doing this and the code breaks.

Cause and effect.

Re: GCC speed (was [PATCH] Isapnp warning)

[Sam Ravnborg]

On Sun, Jun 22, 2003 at 06:58:04PM +0000, Henning P. Schmiedehausen wrote:
> Andrew Morton <akpm@digeo.com> writes:
> 
> Your problem is not the compiler but the build tool / system which
> forces you to recompile all of your kernel if you change only small
> parts.

If you know of any cases where too much is build after a change in
the 2.5 kernel I would like to know that.

In the above keep in mind that the finest granularity is on a file basis,
except for .config, where it is on a config entry granularity.

	Sam

Re: GCC speed (was [PATCH] Isapnp warning)

[Daniel Phillips]

On Sunday 22 June 2003 19:32, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> > As for compilation speed, yes, that sucks.  I doubt there's any rational
> >  reason for it, but I also agree with the idea that correctness and
> > binary code performance should come first, then the compilation speed
> > issue should be addressed.
>
> No.  Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces.  These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.

True, and then gdb works much better as well.  I was really thinking about 
production quality.  Well, I want to have it all, I wonder if the gcc crew 
could come up with a compile speed optimization switch, which produces sucky 
code but does it in record time.

There are many other ways of improving kernel build speed of course.  One of 
the best was to use Keith Owen's kbuild 2.5, which did an impressive job of 
speeding the build up, especially the incremental stuff that matters most to 
developers.  But alas, it died on the horns of politics.

> Compilation inefficiency is the most serious thing wrong with gcc.

If that's the case then it's a good sign I think.

Regards,

Daniel

Re: GCC speed (was [PATCH] Isapnp warning)

[John Bradford]

> No.  Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces.  These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
>
> I'm happy allowing those thousands of people who do not compile kernels all
> the time to shake out any 3.2/3.3 compilation problems.
>
>
> Compilation inefficiency is the most serious thing wrong with gcc.

Code for hardware that almost nobody has anymore isn't easily tested
for subtle compilation errors.

The math emulation code didn't even compile for a while, and that went
unnoticed.  IFF there are substantial benefits to dropping 2.95.3
should we risk drivers for things like obscure SCSI cards being
mis-compiled and randomly corrupting data.

There _must_ be hardware that nobody has tested a gcc 3 compiled
kernel on.

All 2.5.X trees, and most 2.4.x trees have had a _lot_ of testing with
GCC 2.95.3, in a lot of different environments.  Especially in the
case of 2.4.X, a lot of that code hasn't seen significant changes in
the last year or so, and those code paths have been shown to be very
stable with gcc 2.95.3.

Eliminating gcc 2.95.3 support when a lot of people are still using
it, and having a large number of users migrate to gcc 3.3 could
uncover subtle compiler bugs a month or two later, and we'd end up
having to either live with that, or add support for gcc 2.95.3 back
in.

John.

Re: GCC speed (was [PATCH] Isapnp warning)

[Henning P. Schmiedehausen]

Andrew Morton <akpm@digeo.com> writes:

Your problem is not the compiler but the build tool / system which
forces you to recompile all of your kernel if you change only small
parts.

	Regards
		Henning


>Daniel Phillips <phillips@arcor.de> wrote:
>>
>> As for compilation speed, yes, that sucks.  I doubt there's any rational 
>>  reason for it, but I also agree with the idea that correctness and binary 
>>  code performance should come first, then the compilation speed issue should 
>>  be addressed.

>No.  Compilation inefficiency directly harms programmer efficiency and the
>quality and volume of code the programmer produces.  These are surely the
>most important things by which a toolchain's usefulness should be judged.

>I compile with -O1 all the time and couldn't care the teeniest little bit
>about the performance of the generated code - it just doesn't matter.

>I'm happy allowing those thousands of people who do not compile kernels all
>the time to shake out any 3.2/3.3 compilation problems.


>Compilation inefficiency is the most serious thing wrong with gcc.

>-
>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/

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

--- Quote of the week: "Never argue with an idiot. They drag you down
to their level, then beat you with experience." ---

Re: GCC speed (was [PATCH] Isapnp warning)

[Linus Torvalds]

On Sun, 22 Jun 2003, Andrew Morton wrote:
> 
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.

Well, sometimes it _does_ matter from a correctness standpoint. For 
example, gcc without optimizations was simply unusable, because of the 
lack of inlining or the lack of even trivial optimizations (ie static dead 
code removal).

And a (unrelated) gcc list thread showed that even with just -O1, one 
particular project had gone from 131 seconds (gcc-2.7.2) to 180 seconds 
(2.95.3) to 282 seconds (3.3) to 327 seconds (the tree-ssa branch).

		Linus

Re: GCC speed (was [PATCH] Isapnp warning)

[Andrew Morton]

Daniel Phillips <phillips@arcor.de> wrote:
>
> As for compilation speed, yes, that sucks.  I doubt there's any rational 
>  reason for it, but I also agree with the idea that correctness and binary 
>  code performance should come first, then the compilation speed issue should 
>  be addressed.

No.  Compilation inefficiency directly harms programmer efficiency and the
quality and volume of code the programmer produces.  These are surely the
most important things by which a toolchain's usefulness should be judged.

I compile with -O1 all the time and couldn't care the teeniest little bit
about the performance of the generated code - it just doesn't matter.

I'm happy allowing those thousands of people who do not compile kernels all
the time to shake out any 3.2/3.3 compilation problems.


Compilation inefficiency is the most serious thing wrong with gcc.

GCC speed (was [PATCH] Isapnp warning)

[Daniel Phillips]

Hi Andrew,

On Sunday 22 June 2003 04:17, you wrote:
> Compared to 2.95.3, gcc-3.3 takes 1.5x as long to compile, and produces a
> kernel which is 200k larger.
>
> It is simply worthless.

Recently, we did an unscientific but nonetheless informative tour through 
various optimization and compiler version questions here:

   http://marc.theaimsgroup.com/?t=105167074500002&r=3&w=2
   [RFC][PATCH] Faster generic_fls

As a result, my general impression is GCC 3.2 (and, I presume, GCC 3.3 as 
well) comes out better than 2.95.3 in terms of binary performance on x86.  I 
seem to recall there was one case in one algorithm variation on one procesor 
type where 2.95.3 won marginally, and otherwise GCC 3.2 took the trophy every 
time, sometimes by a significant margin.  I was able to get satisfactory 
performance in terms of size as well, by tweaking compile options.  (In 
general, just mindlessly setting O3 seems to work well.)

So I like GCC 3.2 in terms of code quality, at least for the limited set of 
things I've tested, but that's not the only consideration.  Current GCC is a 
whole lot better in terms of C99 compliance and produces better warnings.

As for compilation speed, yes, that sucks.  I doubt there's any rational 
reason for it, but I also agree with the idea that correctness and binary 
code performance should come first, then the compilation speed issue should 
be addressed.  I hope the gcc team does make it a priority at some point.  
For my own part, I'm putting together a cluster to address the compilation 
speed issue, i.e., I don't really care about it.  Even a dual PIII turns in 
satisfactory results in that regard, or a single K7.

Regards,

Daniel

Re: GCC speed (was [PATCH] Isapnp warning)

[Pavel Machek]

Hi!

> If you think 3.[23] are slow, go back and compile with 2.7.2 - it's much 
> faster than the later versions.  I used to yank newer versions of gcc 
> off systems and put 2.7.2 on, I think it was close to 2x faster at 
> compilation and made no difference on BK performance.

Perhaps someone schould create 2.7.3 with long long bugs fixed
and with c99 initializers?
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...