2
edits
Changes
→[0.2] Install an armv7 glibc and re-run the benchmark using dhrystone
===[0.2] Install an armv7 glibc and re-run the benchmark using dhrystone===
Since optimizing the benchmark program using both architectures architecture optimizations revealed the same results, optimizing the system binaries and re-running the benchmark should be able to provide a more concrete contrast between the 2 architectures.
The goal of this release is to find out if upgrading the armv5tel glibc would affect the performance of a C library dependent program such as dhrystone. By re-installing glibc using armv7 optimizations and re-running an armv7 optimized dhrystone; a better benchmark result is expected (Higher DMIPS). The result would be beneficial for Fedora-ARM, for it will help the community decide if armv5tel codes should continually be supported.
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 was built to use an [http://en.wikipedia.org/wiki/Application_binary_interface ABI] called "softfp". Although beagleboardXM (cortex-a8)supports the "hard floating-point" ABI, The Fedora-ARM currently can't afford to waste time to build a system for supporting that supports "hardfp"solely on test purposes. 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.