Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jun 25, 2014 at 11:53 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Wed, Jun 25, 2014 at 5:47 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
>>> Thanks for nice benchmarks. Vladimir.
>>>
>>> Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
>> On the contrary, I don't think rtl unrolling is enabled by default on
>> GCC with level O3/Ofast. There is no unroll dump file at all unless
>> -funroll-loops/-funroll-all-loops is explicitly specified.
> Need to clarify, I did see cases in which GCC's rtl unroller more
> aggressive than llvm's once it's specified.

At -O3 you get more aggressive complete peeling from the GIMPLE
cunroll pass.

Richard.

>> Thanks,
>> bin
>>
>>> on GCC? It doesn't seem increasing code size help performance (164.gzip & 197.parser)
>>> Is there comparisons for O2? I guess that is more useful for typical
>>> mobile/embedded programmers.
>>>
>>> Bingfeng
>>>
>>>> -----Original Message-----
>>>> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
>>>> Vladimir Makarov
>>>> Sent: 24 June 2014 16:07
>>>> To: Ramana Radhakrishnan; gcc.gcc.gnu.org
>>>> Subject: Re: Comparison of GCC-4.9 and LLVM-3.4 performance on
>>>> SPECInt2000 for x86-64 and ARM
>>>>
>>>> On 06/24/2014 10:57 AM, Ramana Radhakrishnan wrote:
>>>> >
>>>> > The ball-park number you have probably won't change much.
>>>> >
>>>> >>>
>>>> >> Unfortunately, that is the configuration I can use on my system
>>>> because
>>>> >> of lack of libraries for other configurations.
>>>> >
>>>> > Using --with-fpu={neon / neon-vfpv4} shouldn't cause you ABI issues
>>>> > with libraries for any other configurations. neon / neon-vfpv4 enable
>>>> > use of the neon unit in a manner that is ABI compatible with the rest
>>>> > of the system.
>>>> >
>>>> > For more on command line options for AArch32 and how they map to
>>>> > various CPU's you might find this blog interesting.
>>>> >
>>>> > http://community.arm.com/groups/tools/blog/2013/04/15/arm-cortex-a-
>>>> processors-and-gcc-command-lines
>>>> >
>>>> >
>>>> >>
>>>> >> I don't think Neon can improve score for SPECInt2000 significantly
>>>> but
>>>> >> may be I am wrong.
>>>> >
>>>> > It won't probably improve the overall score by a large amount but some
>>>> > individual benchmarks will get some help.
>>>> >
>>>> There are some few benchmarks which benefit from autovectorization (eon
>>>> particularly).
>>>> >>> Did you add any other architecture specific options to your SPEC2k
>>>> >>> runs ?
>>>> >>>
>>>> >>>
>>>> >> No.  The only options I used are -Ofast.
>>>> >>
>>>> >> Could you recommend me what best options you think I should use for
>>>> this
>>>> >> processor.
>>>> >>
>>>> >
>>>> > I would personally use --with-cpu=cortex-a15 --with-fpu=neon-vfpv4
>>>> > --with-float=hard on this processor as that maps with the processor
>>>> > available on that particular piece of Silicon.
>>>> Thanks, Ramana.  Next time, I'll try these options.
>>>> >
>>>> > Also given it's a big LITTLE system with probably kernel switching -
>>>> > it may be better to also make sure that you are always running on the
>>>> > big core.
>>>> >
>>>> The results are pretty stable.  Also this version of Fedora does not
>>>> implement switching from Big to Little processors.
>>>