2011/8/1 Loïc Minier loic.minier@linaro.org:
On Sun, Jul 31, 2011, Paulo César Pereira de Andrade wrote:
Hi, sorry for returning back to this discussion.
If I understand correctly, neon will have better support for simd instructions right?
NEON is effectively SIMD instructions, but not all modern SoCs have NEON, e.g. NVidia Tegra2 don't have NEON. It's becoming common place in recent SoCs though.
Either way, I used two simple benchmarks to try to sell myself the idea of breaking compatibility with armv5 or older binaries, but still not convinced, but, as I said, we should use whatever "The Industry" chooses :-)
Depends which industry though. Yes, ARMv5 will be around for a while, but high-end devices, phones, tablets etc. are designed around ARMv7. Depends what your distro targets too; for instance Debian armel targets ARMv4T+ while Ubuntu armel is based of the same sources but targets ARMv7+ and uses Thumb2.
I used for benchmark http://www.tux.org/~mayer/linux/bmark.html and http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI-... and also compared with my home computer (quad)core i5 x86_64, and attached results...
You're likely not going to see much difference switching float ABI alone with common benchmarks, because GCC is clever enough to use the best possible ABI for non-public functions. It's mostly visible when you're crossing library calls with floating points.
You should however definitely see a difference between ARM mode and Thumb-2 mode (which is ARMv6+ only IIRC), as the code is denser and fits more easily in CPU cache.
On simple tests it did not show much difference, but the space saving is quite noticeable. Same for neon, but I believe neon would make more of a difference on vectorized integer operations.
There were many discussions around this on the debian-arm list last year; Konstantinos Margaritis collected benchmarks for hard-float which should be linked from http://wiki.debian.org/ArmHardFloatPort
I did make an initial port of Mandriva using softfp, it has almost all dependencies for a "proper" distro rebuild in place, e.g. most of gtk/gnome, qt4/kde, but it is unofficial, and so far only have a qemu image, or can unpack the image in a chroot; I have been using vnc in a ssh tunnel for testing graphical applications...
But now I am working on repeating the same steps in a hardfp bootstrap, so that, theoretically, any binary for fedora hardfp should just work, and hopefully, the same for linaro.
What is the current state of hardfp toolchain? I ask because softfp, what I earlier considered the most sane engineering option, just builds and works using upstream binutils/gcc, but hardfp requires some hacking; I have been using and building weekly LATEST-4.6 gcc snapshots for quite some time.
HTH
Loïc Minier
Thanks, Paulo