This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64


Point well put. The benchmark suite should have good mixture of
programs with different sizes. SPEC2k programs cluster at the lower
end of the spectrum though.

David

On Thu, Apr 29, 2010 at 12:43 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> Xinliang David Li wrote:
>>>
>>> Thanks for the comments. ?FDO will probably improve SPEC2000 score.
>>> ?Although it is not obvious for some tests because the train data sets
>>> for
>>> them are different from the reference data sets and it might actually
>>> mislead the ?compiler.
>>>
>>> FDO is important for optimizations where all possible data sets do not
>>> change branch probability distribution much. ?IMHO therefore FDO is not
>>> widely used by most of developers (although I am sure that for Google
>>> applications it is extremely important) and therefore I don't measure it
>>> and
>>> it is not so interesting for me. ?Although bigger reason not use FDO is
>>> inconvenience to use it for regular compiler user.
>>>
>>> As for vortex FDO improvement, vortex contains a moderate size loop in
>>> which
>>> most of time is spent. ?The loop has if-then-else on the top loop level.
>>> ?On
>>> all SPEC2000 data sets, one if-branch ?is ?taken practically always
>>> ?(like 1
>>> to ?1,000,000). ? So it is not amazing for me that FDO gives such
>>> improvement for vortex.
>>>
>>
>> Actually what I was trying to say is that LTO will be more powerful
>> when combined with FDO. In other words, I expect LTO + FDO improves
>> over plain FDO more than 1.86%.
>>
>>
>>
>>>>
>>>> It would be great if there is number collected comparing LTO + FDO vs
>>>> plain FDO in the same setup.
>>>>
>>>>
>>>>
>>>
>>> Usually after such posting the comparisons, ?I am getting a lot of
>>> requests.
>>> ?I'd like to do all of them but unfortunately running and the result
>>> preparation takes a lot of my time. ?May be I'll do such comparison next
>>> year.
>>>
>>
>> Ok. Another comment is that using SPEC2000 for performance testing
>> won't be indicative of today's real world program size. Even
>> SPEC2006's largest C++ programs are not that big.
>>
>>
>>
>
> It is very subjective what is today's real world program size. ?Usually it
> reflects what you are working on. ?I understand that Google applications are
> huge and their speed is important for saving money (or energy) for their
> employees. ? Firefox is ?big enough but for regular desktop user 1%
> improvement may be invisible or not important if it is already fast enough.
>
> A math-physics program can be small but its speed may be really important
> because it takes hours or days on fast machine. ? Even big and intensively
> used applications like some logistic system can ?have small ?program parts
> (e.g. ILP ?solver or compression algorithms like gzip for speeding Internet
> communication up) whose optimization are the most important for the
> application and SPEC contains such calculation-intensive code (a lot of
> NP-complete task solvers and math physics programs). ?So I would not say
> using SPEC for performance testing is not important for improving today's
> real world ?size program. ?Of course it is not so important than testing the
> program you are working on. ?In order words, this program is most important
> benchmark for you but probably not for others.
>
> As for me, GCC itself is very important program and SPEC contains it (2000
> old one version and 2006 more recent one). ?So SPEC is pretty important and
> good ?for me (not perfect of course at least because it is not free)
> although it is not the single one which I care of.
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]