gcc 64bit compiler does not offer any speed advantage

[llothar]

I must say i didn't expect this. I just did some measures on FreeBSD
6.2 with gcc 3.4.6 and there is absolutely no significant difference
between 32 and 64 bit mode - neither in compilation speed, nor in
speed of the compiled result.

As a benchmark i took a bootstrap of the SmallEiffel Compiler (which
has 38 files with around 100 kloc). The times i got were very
reliable. The bootstraping (compile the c files from last eiffel
compiler stage, and then use this to regenerated the eiffel compiler
and all tools) took

32Bit: 2,58 (wall), 2,57 (user), 0,3 (system) = exe size:
1,757,177 byte
64Bit: 2,48 (wall), 2,42 (user) , 0,5 (system) = exe size:
2,179,326 byte
This is a measure of the quality of the generated code

The compilation only
13,9 (32bit) <-16,2 (64 bit) sec -O0
33,5 (32bit) <-31,4 (64 bit) sec -02
55,7 (32bit) <-51,9 (64 bit) sec -03

So the new registers are just not giving any benefits that are not
consumed by the additional memory overhead.

I'm mostly surprised that the code generation part of gcc (speed of
the compiler) is also the same, because this is the most terrible
weakness for any of my development (it has to do with how the eiffel
compiler works). MSVC is 16x faster then (using precompiled headers)
gcc (without precompiled headers). I can't compare them again because
the OS are now on different machines but precompiled headers are
almost useless on gcc - and the way Eiffel generates the header file
is already perfect (only one header per c file, and first statement in
each file). I got results from -8% (gcc 4.x) upto 28% (gcc 3.4.6) .

So i always believed that the problem is the code generator of gcc,
which makes sense because Sun Studio 11 on SPARC is 4x faster per Mhz
then the Intel86 code (because of the easy calling conventions for the
compiler) and the tinycc is 9x faster then gcc. Both aren't using
precompiled headers.

But the additional number of registers seems to not reduce the
complexity of the code generator. I really don't understand this. I
guess it is the one-for-all overengineered architecture that slows
down the whole gnu collection.

Unfortunately the only other useable c compiler on linux i could test
was almost as slow as gcc. Seems that Intel does only care about speed
of the executable.

So is there something useable out there (tinycc is unfortunately full
of bugs and not anymore maintained) that is at least 3-5 times faster
then gcc. It would make my development much easier.

Ah yes, on my iMac PPC i also tried it, codewarrior <-gcc was only
giving a little bit less then 2x performance. But this compiler does
not exist anymore. OpenWatcom is also not developed and the lcc-
linux32/lcc-linux64 seem to be not yet available.

[Ian Collins]

llothar wrote:

I don't care (most of the time, at least when i'm using -O0) about the
speed of the compilee,
but the speed of the compiler is very very important for me (because
of problems with
the used eiffel compiler technology). I'm concerned about my most
important resource: time.
If i have a long edit-compile-run cycle it is reducing productivity a
lot.

<OT>Use parallel/distributed building. If your current tools don't
support this, give Sun Studio a try. </OT>

--
Ian Collins.

[llothar]

I'm assuming that you've already tried GCC 4.2, are using -pipe, and are

unable to employ

-pipe is also a myth.

I measured the time with and without -pipe, the effect is absolutely 0
and this makes much sense.

Make magic to cut down on the number of units which need
recompiling each cycle.

This is the problem. It is completely under the control of the Eiffel
compiler

[Keith Thompson]

llothar <ll*****@web.de writes:

>I'm assuming that you've already tried GCC 4.2, are using -pipe, and are
unable to employ

-pipe is also a myth.

I measured the time with and without -pipe, the effect is absolutely 0
and this makes much sense.

[snip]

Please don't snip attribution lines.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

llothar wrote:

>

>If you use all the performance options pertinant for your hardware
and do profile guided optimization, you can get performace pretty
close to the commercial compilers.

Again, you also don't understand it. Seems to be pretty hard for many
people.

I don't care (most of the time, at least when i'm using -O0) about the
speed of the compilee,
but the speed of the compiler is very very important for me (because
of problems with
the used eiffel compiler technology). I'm concerned about my most
important resource: time.
If i have a long edit-compile-run cycle it is reducing productivity a
lot.

And here gcc is hopeless behind compared to LCC-Win32, MSVC, Borland C
or TinyCC.

Take a look at the line wrapping above. If you limit your lines to
about 72 (67 is better) chars this won't occur.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

[stdazi]

On Apr 18, 11:00 pm, llothar <[e-mail] wrote:

If you use all the performance options pertinant for your hardware and
do profile guided optimization, you can get performace pretty close to
the commercial compilers.

Again, you also don't understand it. Seems to be pretty hard for many
people.

I don't care (most of the time, at least when i'm using -O0) about the
speed of the compilee,
but the speed of the compiler is very very important for me (because
of problems with
the used eiffel compiler technology). I'm concerned about my most
important resource: time.
If i have a long edit-compile-run cycle it is reducing productivity a
lot.

You can get productive in this long cycle by optimizing and
contributing patches for gcc :-)

[llothar]

You can get productive in this long cycle by optimizing and

contributing patches for gcc :-)

No you can't contribute patches if the whole system is the problem.
You need a revolution and in computer science this means another
program.

But i don't want to contribute, i want put some money somewhere and
get a good and fast c compiler.

[Mark McIntyre]

On Thu, 19 Apr 2007 10:21:00 +1200, in comp.lang.c , Ian Collins
<ia******@hotma il.comwrote:

>llothar wrote:

>I don't care (most of the time, at least when i'm using -O0) about the
speed of the compilee,
but the speed of the compiler is very very important for me (because
of problems with
the used eiffel compiler technology). I'm concerned about my most
important resource: time.
If i have a long edit-compile-run cycle it is reducing productivity a
lot.

<OT>Use parallel/distributed building. If your current tools don't
support this, give Sun Studio a try.

You can do this with gcc too - check out the -j switch to make, and
consider using a more sophisticated build environment which can
distribute jobs over multiple machines. ISTR there are some
python-based tools which assist with this.

</OT>
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On 19 Apr 2007 10:05:21 -0700, in comp.lang.c , llothar
<ll*****@web.de wrote:

>But i don't want to contribute, i want put some money somewhere and
get a good and fast c compiler.

Then feel free to do so, but please don't waste our time here by
complaining about an offtopic toolset for no apparent reason.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Bos]

llothar <ll*****@web.de wrote:

You can get productive in this long cycle by optimizing and
contributing patches for gcc :-)

No you can't contribute patches if the whole system is the problem.
You need a revolution and in computer science this means another
program.

But i don't want to contribute, i want put some money somewhere and
get a good and fast c compiler.

Then stop using, and more importantly stop whingeing about, Ganuck.

Richard

[Neil Booth]

llothar wrote:

>If you use all the performance options pertinant for your hardware and
do profile guided optimization, you can get performace pretty close to
the commercial compilers.

Again, you also don't understand it. Seems to be pretty hard for many
people.

I don't care (most of the time, at least when i'm using -O0) about the
speed of the compilee,
but the speed of the compiler is very very important for me (because
of problems with
the used eiffel compiler technology). I'm concerned about my most
important resource: time.
If i have a long edit-compile-run cycle it is reducing productivity a
lot.

And here gcc is hopeless behind compared to LCC-Win32, MSVC, Borland C
or TinyCC.

Please don't compare GCC with TinyCC. GCC attempts to conform to the
standard; whereas TinyCC doesn't do a whole bunch of things remotely
correctly, such as supporting trigraphs, handling whitespace
correctly and expanding simple macros properly. Fixing what TinyCC
doesn't do right will necessarily slow it down a lot.

Despte that I do agree GCC is unjustifiably slow.