Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)

[Robert Dewar]

Vladimir Makarov wrote:
> Duncan Sands wrote:
>> Hi Steven,
>>
>>>> I think Jack wasn't suggesting that dragonegg should be changed to 
>>>> not be
>>>> a plugin any more.  I think he was suggesting that it should live in 
>>>> the gcc
>>>> repository rather than the LLVM repository.
>>> So, no offense, but the suggestion here is to make this subversive
>>> (for FSF GCC) plugin part of FSF GCC? What is the benefit of this for
>>> GCC? I don't see any. I just see a plugin trying to piggy-back on the
>>> hard work of GCC front-end developers and negating the efforts of
>>> those working on the middle ends and back ends.
>> I'm sorry you see the dragonegg project so negatively.  I think it is 
>> useful
>> for gcc (though not hugely useful), since it makes it easy to compare 
>> the gcc
>> and LLVM optimizers and code generators, not to mention the gcc and LLVM
>> approaches to LTO.  If LLVM manages to produce better code than gcc 
>> for some
>> testcase, then it is a convenient tool for the gcc devs to find out 
>> why, and
>> improve gcc.  If gcc is consistently better than LLVM then there's 
>> nothing to
>> worry about!  Of course, right now it is LLVM that is mostly playing 
>> catchup
>> with gcc, so for the moment it is principally the LLVM devs that get 
>> to learn
>> from gcc, but as LLVM improves the other direction is likely to occur 
>> more
>> often.
> I've tried to compare gcc4.5 and dragonegg a week ago on SPEC2000 on a 
> Core I7.
> Here are some results.
> 
>   Only SPECIn2000 for x86_64 has been compiled fully successfully by
> dragonegg.  There were a few compiler crashes including some in LLVM
> itself for SPECFP2000 and for SPECINT2000 for x86.
> 
> So here is SPECInt2000 for x86_64 comparison:
> 
> dragonegg: -O3 (with LLVM release build)
> gcc4.5: -O3 -flto (--enable-checking=release)
> 
>           Compilation Time  SPECINT2000
> Dragonegg 122.85user         2572
> gcc-4.5   283.49user         2841
> 
>   On integer benchmarks, dragonegg generates about 11% slower code.
> One interesting thing is that dragonegg is a really fast compiler.  It
> is 2.3 times faster than gcc.

Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on current
PC's, using just one core). GCC has taken a decision to favor
performance of the code absolutely over compiler performance.
That's not such a bad bet given how fast machines are getting.
So I think this compile time advantage is not that interesting.
> 
> Draggonegg generates smaller text sections but bigger data sections.
> Unfortunately, my scripts measure and compare only text sections.  Therefore
> I am not posting this text code size comparison because it has no 
> sense.  But looking
> at small benchmarks, I got an impression that gcc generates smaller code 
> (text + data)
> in general than dragonegg.

Usually you will find that to a first order approximation, speed and
size are linearly related.