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

[Vladimir Makarov <vmakarov@redhat.com>]

Robert Dewar wrote:
> 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.
For me definitely.  Also as I wrote I would not be too much worried 
about it.  GCC looks good in comparison with other industrial compiler 
with compile time (and code size too) point of view. Here I mean Intel, 
SunStudio, PathScale, Open64 ones.
>
>>
>> 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.
>
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).