Supporting Architectures above armv5tel

Project Name

Supporting Architectures Above armv5tel

Project Description

The armv5tel architecture version is supported by some common devices such as the Marvell Feroceon processors used in most plug computers. However, later versions of the architecture support advanced features, and using armv5tel code on those processors may result in suboptimal performance.

This project will research ways that Fedora-ARM could support higher processor versions effectively without recompiling the entire Fedora package universe -- for example, by providing an armv7 + hardfp glibc and kernel. This involves performance testing across multiple devices.

Initial contacts: ctyler, PaulW

Project Leader(s)

Mark Eamiguel

Project Contributor(s)

IRC:
#ubuntu-arm (persia)
#gentoo-embedded (solar and steev_)

Project Details

What the project is all about

Currently, Fedora only supports armv5tel hardware. With the introduction of armv7 architecture, Fedora-ARM is planning to upgrade its Fedora Universe. While it seems logical, re-compiling the whole Fedora package is a strenuous task; therefore before deciding to recompile, Fedora-ARM needs to make sure if optimizing certain system binaries to use armv7 architecture proves significant performance difference against the currently used armv5tel architecture.

This project aims for that sole purpose. By running a benchmark and compiler optimizations, Fedora-ARM can contrast both technologies and use the results to decide if it's really worth to recompile the whole Fedora Universe to use armv7 architecture.

Below is a list of technologies by armv7.

ARMv7 Technologies:

• Thumb®-2/ Thumb
• NEON™
• VFPv3

There are currently 2 ARMv7 (beagleboard & beagleboard XM) builders in the Fedora ARM farm. These builders are running builds on ARMv5tel. This project will focus in using the beagleboardXM builder cdot-beagleXM-0-3

Specifications for the cdot-beagleboardXM-0-3 builder

---

cdot-beagleboardXM-0-3 builder

beagleboardXM specific

beagleboardXM hardware page

cat /proc/version

Linux version 2.6.32 (ubuntu@ip-10-204-115-71) (gcc version 4.3.3 (GCC) ) #3 PREEMPT Wed Aug 18 15:53:03 UTC 2010

cat /proc/cpuinfo

Processor  : ARMv7 Processor rev 2 (v7l)
BogoMIPS  : 515.72
Features  : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant  : 0x3
CPU part  : 0xc08
CPU revision  : 2
Hardware  : OMAP3 Beagle Board
Revision  : 0020
Serial  : 0000000000000000

cat /proc/meminfo

MemTotal: 498716 kB

rpm -q glibc
glibc-2.11-2.fa3.armv5tel

Project Plan

Goals for each release:

[0.1] Optimize and run a benchmark program specifically designed to make use of glibc

Any packages compiled for the beagleboards can be installed without optimization. So far, in the case of cdot-beagleXM-0-3 packages are compiled without it. Without optimizations, software installed in a system can only run on optimal performance. In order to make use of ARMv7 architecture features, editing the CFLAGS to use arm optimization options will let the compiler attempt to improve the performance and/or code size of the program; resulting in a more efficient/faster system.

The goal of this release is to run a benchmark software named Dhrystone on cdot-beagleXM-0-3 and record the results. Three (3) runs are required: No optimization, Optimized for armv5tel, and Optimized for armv7. Dhrystone is chosen as the benchmark software mainly, to test the general system performance of cdot-beagleXM-0-3 and to test how much performance gain can be expected from optimizing a program. Other reasons include:

Reasons for using Dhrystone

• ARM® recognizes the program and uses it as a performance attribute of their processors.
• Dhrystone provides a more meaningful MIPS (Million Instructions Per Second) because results are compared to a reference machine.
• Dhrystone numbers reflect the performance of the C compiler and libraries more so than the performance of the processor itself. (considered as a weakness of the program)
• Check if armv7 optimization options and armv5tel optimization options differ significantly in system performance boost

Test Result:

Legend:

• Normal = 758.869322709 DMIPS
• Optimized for armv5tel = 1034.82179852 DMIPS
• Optimized for armv7 = 1034.82179852 DMIPS
  

The benchmark graph shows that optimization increased the overall performance of cdot-beagleXM-0-3 by 36%. The results for both armv5tel and armv7 optimizations are the same. (It can be assumed that the armv5tel glibc impacts the performance of C library dependent programs such as Dhrystone). The data gathered can be used as a reference for conducting 0.2 project release.

[0.2] Install an armv7 glibc and re-run the benchmark using dhrystone

Requires:

glibc binaries

In order for a successful glibc armv7 build, the file /usr/lib/rpm/redhat/rpmrc needs edit to use armv7 build options. Using mock; a downloaded glibc source can be rebuilt. Once finished, the binaries can then be installed locally to the system using rpm OR a local repository can be created enabling the use of yum.

Test Result:

The Dhrystone (DMIPS) results never changed. The benchmark brought the same, exact number of DMIPS. Although Dhrystone does make use of C library functions and is assumed that the glibc would have effects on the program; the results proved that upgrading the glibc did not bring what's expected.

It is proven that armv7 and armv5 arch optimizations provide the same level of performance especially when running C library dependent programs on cdot-beagleXM-0-3 builder. Why is it possible when armv7 architecture is supposed to be better than armv5tel? One big answer is that the system tested currently is built to use an ABI called "softfp". Although beagleboardXM (cortex-a8)supports the "hard floating-point" ABI, The Fedora-ARM currently can't afford to waste time in recompiling the packages to support "hardfp". To make things a little clearer, cdot-beagleXM-0-3 can't use the technology offered by ARM-cortex-a8 processor because of how the system (down to the lowest level) is built.

ARM Floating point is a pretty big topic, provided are some links to help you understand more.

• Standard for floating point arithmetic
• ARM Floating Point
• arm-hardfloat wiki
• Software floating point in GCC

In conclusion, Fedora-ARM can continue to use armv5tel codes on armv7 machines. Deciding to recompile the whole universe for armv7 is somehow an inconvenient recommendation for now.

[0.3]Thoughts for a future project

The previous test didn't leave an opportunity for me to work on [0.3] Release. Although the comparison is done, and the results are gathered; One last option to test armv7 technology still remains: "Rebuild everything!" This recommendation would undoubtedly reveal the performance difference of armv7 against armv5tel; but at the same time would be a big project "not suitable for a single person to work on".

I hope that this project page including the Dhrystone How To page can be of use for future ARM based project reference.

Things to learn

-rpmmacros -Dhrystone 2.1
-gcc ARM optimizations
-Ways of benchmarking ARM processors
-gcc install options
-Compiling kernel and glibc
-Familiarization with ARM hardware

HOW TOs

A guide for using Dhrystone benchmark

Project News

December 15th, 2010 - Added the Dhrystone How to Page

December 9th, 2010 - Project page update (0.1 Release)

November 22nd, 2010 - Release 0.1 test results posted

November 4th, 2010 - Compiler optimization options ready for testing, project page updated

October 19th, 2010 - Chris Tyler explained more about the project, including goal 0.1

October 15th, 2010 - Project page updated (Things to learn)