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