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.

 

[jacob navia]

llothar a écrit :

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.

I would not expect anything else. For what reason you would think
64 bit is better?

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

What machine were you using? Without that, absolute times are
meaningless.

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.

Yes. Code bloat, and larger memory footprint eat away the benefits
of the new registers.

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).

lcc-win32 is 20 x faster than gcc. I think most compilers are faster
than gcc since gcc has never cared about this. The team has apparently
other objectives.

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.

Exactly. One of the symptoms for this situation is that -O2 generates
BETTER code thanh -O3 ... -O9.

The problem with this type of software is that the only thing that
people are interested in is to put some more code, since the
recognition goes to "the guy that added feature xxx to gcc" and
never to the "guy that erased unneeded feature xxx from gcc".

This means that evertbody has his/her pet interest with the
project, and not a lot of people care about the project in general.

This means that many features get added to the software but never
a reviw of all the optimizations is done to see if it is wortwhile
to KEEP them.

Another big difficulty of the gcc project is that it is a compiler
that should run anywhere, what means a lot of back ends, and
therefore a lot of problems. Microsoft has less problems since it runs
essentially on x86 and then only in one operating system...

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.

You could use lcc-lin64 but it is NOT free under linux, you have
to buy it.

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.

Yes, use lcc-lin64.

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.

They are available but need some tweaking.

 

[llothar]

I would not expect anything else. For what reason you would think

64 bit is better?

Only for the better register model. For todays computer speed the CPU
ISA seems really not so important any more. It's good to see that
the large address space is not giving a high penality. But i have to
check the
speed of the Boehm-Weisser-GC before i make a final comparision.

What machine were you using? Without that, absolute times are
meaningless.

It's an AthlonX2 4400 but no parallel execution. The numbers itself
are
irrelevant I just wanted to point out how equal the numbers are
(less then 1%) and even the exe size is only 20% larger.

At first i even expected the program was wrongly compiled so
i added a "assert(sizeof(void*) == 8)" but it was okay.

lcc-win32 is 20 x faster than gcc. I think most compilers are faster
than gcc since gcc has never cared about this. The team has apparently

Indeed. I see this as a huge problem.

You could use lcc-lin64 but it is NOT free under linux, you have
to buy it.

Don't have a problem as long as the price is reasonable. But i need
some more
information. I purchased Code-Warriors Linux and Kylix. Both were
terrible mistakes
and i never got Kylix compile a simple hello world. But i talked with
Friedrich about
it and it seems that you are going a better way. Is there any website,
i looked at
his Q website and couldn't find anything.

 

[Stephen Sprunk]

llothar a écrit :

I would not expect anything else. For what reason you would think
64 bit is better?

It all depends on the specific code. Some programs get a huge boost, nearly
100%, from the additional registers. Others get hammered by the cache
effects of larger pointers. Most programs are not significantly affected by
either factor -- or they cancel each other out.

S

 

[user923005]

Your post is more topical in a GCC compiler group.

I guess you are using it wrong, or in areas where there is no benefit.

In bitboard chess programs (which need 64 bit integers) there is a big
speedup. If your program does not use 64 bit integers heavily, there
is no reason to expect a big speed increase (unless you need to access
more than 2 GB of RAM, which is another place where 64 bit model
shines).

At any rate, if you want to get better performance using the GCC
compiler suite, why not ask in one of the myriad GCC compiler
newsgroups?

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.

 

[llothar]

It all depends on the specific code.

Yes and Compilation seems to be extremely difficult for current CPU's.
I also got no significant difference when i moved from AthlonX2 to a
Core2Duo System where i expected from other application benchmarks
that there is much more benefit of larger caches (4MB instead of 1MB).
But no, almost linear to the very minor improvent in CPU frequency.

 

[llothar]

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.

 

[William Ahern]

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.

<OT>

If you're proficient enough, maybe it might be worth your time to invest in
TinyCC development. The project is on the verge of a fork already. There are
two developers in particular who have very nearly forked the project, given
that they meticulously maintain patch sets. It just needs that extra push
and promise of community involvement, and one of them might actually pick up
the torch.

Alternatively, you can always try KenCC from the Plan9 project. Google
Summer of Code has a project for porting it to POSIX systems.

I've never had any luck with TenDRA.

Time is indeed precious, but in this day and age of Free Software complaints
aren't worth much when one can fix the issues themselves. You can find time
in the damnedest places....

I'm assuming that you've already tried GCC 4.2, are using -pipe, and are
unable to employ Make magic to cut down on the number of units which need
recompiling each cycle.

</OT>

 

[Mark McIntyre]

As a benchmark i took a bootstrap of the SmallEiffel Compiler (which
has 38 files with around 100 kloc).

Too trivial an example. Try running the greeks calculation for a book
of structured credit derivatives....

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

Size is a measure of quality?????!!

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

More likely your test case is too limited. You need something that
really exercises the 64-bitness of the system. Compilation isn't
likely to be that beast.

By the way, your post is offtopic in CLC, which is for discussing the
C Language, not quality of implementations, however interesting.
--
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]

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

Be careful not to be condescending to your listeners, they're likely
to object to being told they're stupid. Consider whether you properly
explained yourself in the first case.

If i have a long edit-compile-run cycle it is reducing productivity a lot.

Sounds like you could try optimising your code perhaps, instead of
blaming your tools (talking of being condescending).

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

You are free to invest your time in resolving this, instead of just
criticising the implementors of gcc who its worth remembering don't
get paid to implement gcc, and do it in their spare time.
--
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

 

[Ian Collins]

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>

 

[CBFalconer]

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.securityfocus.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

 

[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]

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

 

[stdazi]

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]

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

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]

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]

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.