This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, "gcc.gcc.gnu.org" <gcc at gcc dot gnu dot org>
- Date: Tue, 24 Jun 2014 11:06:32 -0400
- Subject: Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM
- Authentication-results: sourceware.org; auth=none
- References: <53A98705 dot 10909 at redhat dot com> <53A98CE2 dot 9080108 at arm dot com> <53A98F0A dot 7000802 at redhat dot com> <53A991D7 dot 6070709 at arm dot com>
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.