2011/3/30 Michael Hope michael.hope@linaro.org:
On Tue, Mar 29, 2011 at 5:40 PM, Barry Song 21cnbao@gmail.com wrote:
2011/3/24 Michael Hope michael.hope@linaro.org:
Hi Barry. The short answer is 'it depends' :)
GCC is more than a compiler and includes other things such as a runtime library (libgcc) and hooks into the libc for features like thread local storage. These are built for the architecture and floating point unit options you pass to GCC's configure, so if you want one toolchain that runs everywhere then you need to configure it for the lowest common denominator (normally a ARMv5T in ARM mode with no FPU). A similar argument applies to GLIBC.
The next question is, does this matter for your application? What workload will your product run and will it be meaningfully affected by this lowest common denominator build? * If your application uses a lot of floating point, then the lack of FPU support in GLIBC matters
Completely right. I got a linaro 4.5 by:
sudo add-apt-repository ppa:linaro-maintainers/toolchain sudo apt-get update sudo apt-get install gcc-4.5-arm-linux-gnueabi
Then I did WHETSTONE benchmark on a low-frequency cortex A9 FPGA with vfpv3.
Result showed linaro by apt-get is using generic glibc in fact. its gave only 3.3 WHETSTONE MIPS. Then i compiled a glibc with vfpv3 support to replace the glibc by apt-get, the new toolchain gave 16.7 WHETSTONE MIPS, 400% improvement in WHETSTONE.
Whetstone is a floating point benchmark, so I'd expect this type of improvement.
* If your product has limited memory, then the smaller code size of Thumb-2 is worthwhile * If you need to squeeze out another 5 % in performance, then using ARMv7 instead of ARMv5 will help
Completely right. I did a edn benchmark from http://www.mrtc.mdh.se/projects/wcet/wcet_bench/edn/edn.c. EDN can show memory and fixed-point performance. My testing result shows edn has a 5-10% performance improvement by linaro 4.5 with armv7_a option.
Nice :) This matches what I've seen.
Then my conclusion is that the best choice for cortex A9 with vfpv3 is
- using linaro gcc 4.4/4.5 with ARMV7 optimization
- using glibc compiled with vfpv3 supporting
A strange phenomenon i found was nbench would enter dead loop in ASSIGNMENT case. It could finish ASSIGNMENT case forever. nbench can be downloaded from http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz. I haven't time to figure out whether it is a linaro gcc bug. Then i just ignore this case by writing NBENCH.CONF like the following: CUSTOMRUN=T DONUMSORT=T DOLU=T DOSTRINGSORT=T DOBITFIELD=T DOEMF=T DOFOUR=T DOASSIGN=F ASSIGNMINSECONDS=1 DOHUFF=T DOIDEA=T
If you have time, may you help to check the reason?
I couldn't reproduce this, sorry. I built nbench using gcc-linaro-4.5-2011.03-0 using both -O3 -mtune=cortex-a9 -mfpu=vfpv3-d16 and -O3 -mtune=cortex-a9 -mfpu=neon and in both cases ASSIGNMENT completes.
Thanks. i will check whether it is our chip issue.
here one question: how much arm-linux-gnueabi-gcc depends on glibc version?
i run apt-get linaro 4.4, then got linaro 4.5 too. i found 4.5 was using glibc 2.12, but old 4.4 was using 2.11. apt-get 4.5 modified glibc from 2.11 to 2.12. But 4.4 could still use new glibc to compile and we haven't had any problem by now. I even recompiled a glibc 2.13 to replace current 2.12, but i didn't recompile gcc based on the glibc, the toolchain 4.4 and 4.5 can still work.
As i know, we compile arm-linux-gnueabi-gcc by following steps: 1. compile gcc 1, bootstrap in fact 2. compile glibc by gcc1 3. compile gcc2 based on glibc from step 2.
why can toolchain still work well by the steps? 1. keep arm-linux-gnueabi-gcc unchanged 2. replace glibc So i am not sure whether any hidden problem exist by replacing glibc simply.
one more question, my ubuntu 10.10 always said "/lib/libc.so.6: file not recognized: File format not recognized" if i enabled c++ language when compiling linaro gcc 4.4 and 4.5. Then i can't install libstdc++-v3 with errors like: /bin/sh: line 3: cd: arm-none-linux-gnueabi/libstdc++-v3: No such file or directory make[1]: *** [install-target-libstdc++-v3] Error 1
In fact, my version matches:
$ /lib/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.12.1-0ubuntu10.2) stable release version 2.12.1, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.35 system on 2011-01-21. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: http://www.debian.org/Bugs/.
$ uname -a Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux
-- Michael