Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
Vladimir Makarov
vmakarov@redhat.com
Wed Apr 21 20:54:00 GMT 2010
Robert Dewar wrote:
>
>> I am agree with this for moderately optimizing compilers. But for
>> highly optimizing compilers it might be no true. Intel generates
>> much better and bigger code than gcc. Although it might be mostly
>> because of code versioning (including one for different subtargets).
>
> I don't think this is true if you select the appropriate option in
> ICC to generate code for just one target, but of course if you let
> ICC generate code for multiple targets (e.g. GenuineIntel with SSE
> vs AuthenticAMD without SSE), then of course you get larger objects,
> since you have a run time test and then essentially two separate
> compilations of the same code in the same object.
>
>
It is hard to find appropriate options even if we put mutliple targets
code generation away. For example, if you use -fast for ICC it means
using -static libraries which makes code much bigger.
Although it is not right argument to what you mean. But example about
vectorization would be right. ICC vectorizes many more loops than gcc
does. Vectorized loops is much bigger in size than their non-vectorized
variants. So faster code does not mean smaller code in general. There
are a lot of optimization which makes code bigger and faster: like
function versioning (based on argument values), aggressive inlining,
modulo scheduling, vectorization, loop unrolling, loop versioning, loop
tiling etc. So even if the both compiler do the same optimizations and
if one compiler is more successful in such optimizations, the generated
code will be bigger and faster.
More information about the Gcc
mailing list