2011/3/30 Michael Hope <michael.h...@linaro.org>:
> On Tue, Mar 29, 2011 at 5:40 PM, Barry Song <21cn...@gmail.com> wrote:
>> 2011/3/24 Michael Hope <michael.h...@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
>> 1. using linaro gcc 4.4/4.5 with ARMV7 optimization
>> 2. 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
>
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
