>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 article <[EMAIL PROTECTED]>
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
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 the
said Meggy
--
- Original Message -
From: "Hacksaw" <[EMAIL PROTECTED]>
To: "Alexander V. Bilichenko" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
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
t: 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
gt;
Cc: <[EMAIL PROTECTED]>
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.
In article <[EMAIL PROTECTED]> 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 t
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: 100 iteration. 3% slower
> than 2.95.
> test example - hash table add/remove - 4% slower (compiled both
> with -O2 -march=i686).
> Wh
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: 100 iteration. 3% slower than
> > 2.95. test example - hash table add/remove - 4% slower (compi
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: 100 iteration. 3%
> slower than 2.95.
> test example - hash table add/remove - 4% slower (compiled both
> with -O2 -march=i68
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: 100 iteration. 3% slower than
> 2.95. test example - hash table add/remove - 4% slower (compiled
> both with -O2 -march=i686).
> Why have this ve
Hello All!
Some tests that I have recently check out.
kernel compiled with 3.0 (2.4.5) function call: 100 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
13 matches
Mail list logo
