GCC3.0 Produce REALLY slower code!

GCC3.0 Produce REALLY slower code!

[Alexander V. Bilichenko]

Hello All!
Some tests that I have recently check out.
kernel compiled with 3.0 (2.4.5) function call: 1000000 iteration. 3% slower
than 2.95.
test example - hash table add/remove - 4% slower (compiled both
with -O2 -march=i686).
Why have this version been released?
Best regards,
Alexander         mailto:dmor@7ka.mipt.ru

Re: GCC3.0 Produce REALLY slower code!

[Rik van Riel]

On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote:

> Some tests that I have recently check out. kernel compiled with
> 3.0 (2.4.5) function call: 1000000 iteration. 3% slower than
> 2.95. test example - hash table add/remove - 4% slower (compiled
> both with -O2 -march=i686).

> Why have this version been released?

It would be better to ask that to the GCC people, but I
suspect it was released because it was (almost) stable
and the only way to do the last small tweaks to the code
would be to have it tested in the field ?

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: GCC3.0 Produce REALLY slower code!

[Daniel Phillips]

On Monday 25 June 2001 00:44, Alexander V. Bilichenko wrote:
> Hello All!
> Some tests that I have recently check out.
> kernel compiled with 3.0 (2.4.5) function call: 1000000 iteration. 3%
> slower than 2.95.
> test example - hash table add/remove - 4% slower (compiled both
> with -O2 -march=i686).
> Why have this version been released?
> Best regards,
> Alexander         mailto:dmor@7ka.mipt.ru

Err, thanks for the benchmarks, but how does this qualify as 'really' slower?

Disassemblies of the inner loops would be very informative.

--
Daniel

Re: GCC3.0 Produce REALLY slower code!

[Luigi Genoni]

On Sun, 24 Jun 2001, Rik van Riel wrote:

> On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote:
>
> > Some tests that I have recently check out. kernel compiled with
> > 3.0 (2.4.5) function call: 1000000 iteration. 3% slower than
> > 2.95. test example - hash table add/remove - 4% slower (compiled
> > both with -O2 -march=i686).
>
> > Why have this version been released?
>
> It would be better to ask that to the GCC people, but I
> suspect it was released because it was (almost) stable
> and the only way to do the last small tweaks to the code
> would be to have it tested in the field ?
>
Actually I think the just one very good reason to use gcc 3.0 is if you
are programming using C++. It's a kind of paradise for C++ programmers.
So I had to install it on my servers used by C++ programmers, they were
so happy...
To use C, it's better to avoid gcc 3.0, it's just slower.
All bench i did, it's slower about 3/5% depending on the kind of code.
It is faster just on some floating point with really small
code, (I used optimizzations for athlon CPU).

Luigi

Re: GCC3.0 Produce REALLY slower code!

[Matthias Andree]

On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote:

> Hello All!
> Some tests that I have recently check out.
> kernel compiled with 3.0 (2.4.5) function call: 1000000 iteration. 3% slower
> than 2.95.
> test example - hash table add/remove - 4% slower (compiled both
> with -O2 -march=i686).
> Why have this version been released?

Because it comes with various other improvements, among them better
error detection, better C++ support, integrated GCJ (but regretfully
still without Ada 95), to name a few reasons.

3% to 4% loss in a first release of a new major release is not a big
deal, although I found similar results on leafnode's texpire.
However, 3% do not warrant me spending my time complaining. Maybe some
optimization is missing, maybe other operations than the ones you
checked are faster. So there.

You might run an entire benchmark suite and report back, tough. :-)

Re: GCC3.0 Produce REALLY slower code!

[Thomas Pornin]

In article <Pine.LNX.4.33.0106250142070.1314-100000@Expansa.sns.it> you write:
> All bench i did, it's slower about 3/5% depending on the kind of code.

On Alpha machines (ev4 and ev56), it seems actually to be the opposite
on integer calculation: gcc-3.0 produces code up to 5% faster than
gcc-2.95.2. The result is still 25% behind the Compaq C compiler,
though.

By the way, the installation procedure is mostly buggy on old Alpha
systems (RedHat 5.1 -> binutils 2.9, glibc 2.0.7). I do not mind gcc
having some requirements about versions of such other tools, but it
could be made a bit more explicit, and the configuration script should
also emit some warnings (it detects the versions installed, it just does
not bother reporting the potential problem).


	--Thomas Pornin

Re: GCC3.0 Produce REALLY slower code!

[Alexander V. Bilichenko]

Although I just wanna say that there is no reason trying compile kernel with
new shiny GCC 3.0 ;-). The result will be in kernel slowdown.

Maybe, we can try to use Intel C compiler for some important ;-) (beta
version work with linux).

Best regards,
Alexander                  mailto:www@2ka.mipt.ru
------------------------------------------------------
Let start the war, said Meggy
------------------------------------------------------
----- Original Message -----
From: "Matthias Andree" <matthias.andree@stud.uni-dortmund.de>
To: "Alexander V. Bilichenko" <dmor@7ka.mipt.ru>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, June 25, 2001 1:16 PM
Subject: Re: GCC3.0 Produce REALLY slower code!


> On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote:
>
> > Hello All!
> > Some tests that I have recently check out.
> > kernel compiled with 3.0 (2.4.5) function call: 1000000 iteration. 3%
slower
> > than 2.95.
> > test example - hash table add/remove - 4% slower (compiled both
> > with -O2 -march=i686).
> > Why have this version been released?
>
> Because it comes with various other improvements, among them better
> error detection, better C++ support, integrated GCJ (but regretfully
> still without Ada 95), to name a few reasons.
>
> 3% to 4% loss in a first release of a new major release is not a big
> deal, although I found similar results on leafnode's texpire.
> However, 3% do not warrant me spending my time complaining. Maybe some
> optimization is missing, maybe other operations than the ones you
> checked are faster. So there.
>
> You might run an entire benchmark suite and report back, tough. :-)
> -
> 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: GCC3.0 Produce REALLY slower code!

[Alexander V. Bilichenko]

Here is link to Intel C compiler, that provide really faster code.

http://developer.intel.com/software/products/compilers/linuxbeta.htm


----- Original Message -----
From: "Tomasz Kłoczko" <kloczek@rudy.mif.pg.gda.pl>
To: "Alexander V. Bilichenko" <dmor@7ka.mipt.ru>
Sent: Monday, June 25, 2001 3:40 PM
Subject: Re: GCC3.0 Produce REALLY slower code!


> On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote:
>
> > Although I just wanna say that there is no reason trying compile kernel
with
> > new shiny GCC 3.0 ;-). The result will be in kernel slowdown.
> >
> > Maybe, we can try to use Intel C compiler for some important ;-) (beta
> > version work with linux).
>
> Is there avalaible any free/evaluation version this compiler ?
>
> kloczek
> --
> -----------------------------------------------------------
> *Ludzie nie mają problemów, tylko sobie sami je stwarzają*
> -----------------------------------------------------------
> Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail:
kloczek@rudy.mif.pg.gda.pl*
>

Re: GCC3.0 Produce REALLY slower code!

[Hacksaw]

>Here is link to Intel C compiler, that provide really faster code.
>
>http://developer.intel.com/software/products/compilers/linuxbeta.htm

A quote from the site:

* Not all of the GNU C language extensions, including the GNU inline assembly 
format, are currently supported and, due to this, one cannot build the Linux 
kernel with the beta release of the Intel compilers and the initial product 
release.

Re: GCC3.0 Produce REALLY slower code!

[Alexander V. Bilichenko]

There is not so much code in asm, so it's easy to patch code
the most reasonable method is to write parsing program for that

Best regards,
Alexander         mailto:dmor@7ka.mipt.ru
------------------------------------------------------
Let's start the war, said Meggy
------------------------------------------------------
----- Original Message -----
From: "Hacksaw" <hacksaw@hacksaw.org>
To: "Alexander V. Bilichenko" <dmor@7ka.mipt.ru>;
<linux-kernel@vger.kernel.org>
Sent: Tuesday, June 26, 2001 3:30 AM
Subject: Re: GCC3.0 Produce REALLY slower code!


> >Here is link to Intel C compiler, that provide really faster code.
> >
> >http://developer.intel.com/software/products/compilers/linuxbeta.htm
>
> A quote from the site:
>
> * Not all of the GNU C language extensions, including the GNU inline
assembly
> format, are currently supported and, due to this, one cannot build the
Linux
> kernel with the beta release of the Intel compilers and the initial
product
> release.
>
>

Re: GCC3.0 Produce REALLY slower code!

[Hacksaw]

Well, I haven't gone and looked at every line of assembler, but I'd bet this 
is a hasty characterization.

According to someones recent count there are around 144000 lines of assembler 
in the 2.4.2 kernel.

It seems to me you'd have to jump through a lot of hoops to test this compiler.

Then there's the other question: Why should we test a compiler that seems to 
be quite proprietary? The invitation indicates it uses FLexLM to manage the 
license.

I somehow doubt Linus or just about anyone else is going to care, save for the 
folks in Intel, who can do this for themselves just fine.

But, hey, I won't try and stop you. Have fun.

Re: GCC3.0 Produce REALLY slower code!

[Thomas Pornin]

In article <200106260121.f5Q1LuE14141@habitrail.home.fools-errant.com>
you write:
> Then there's the other question: Why should we test a compiler that
> seems to be quite proprietary?

Apart from questions of optimization, compiling the same code with two
different compilers is a very good way to find bugs, both in the code
and in the compilers.

Besides, the kernel is, for now, dependent on many gcc features; but
it might be worth thinking about writing code a bit more "standard",
just in case another free C compiler emerges on some specific arch. Then
again, aiming at compiling with several compilers is one way to achieve
portability.

(yet I do not believe it will happen anyday soon)


	--Thomas Pornin

Re: GCC3.0 Produce REALLY slower code!

[Hacksaw]

>Apart from questions of optimization, compiling the same code with two
>different compilers is a very good way to find bugs, both in the code
>and in the compilers.

I agree that this is a workable idea. On the other hand, I'd bet Linus would 
put that idea right up there with shipping a debugger in kernel.

If you need to use tricks like that to find bugs, you might not understand 
your code as well as you should.

The optimization angle is an important one. I'd like to see intel's 
optimizations tested against the kernel, *and then released in gcc*, or 
something specialized like pgcc. (Anyone know if pgcc ever compiled a good 
kernel that was notably faster?)

Overall, though, I'd bet such optimizations would give no more than a few 
percentage points of speed overall. The big gains are to be had by serious 
redesign like the cache change or the zero copy stuff.

When your design is mediocre, an optimizing compiler makes the the wrong idea 
faster.