On Android Froyo, with the Linpack program (http:// www.greenecomputing.com/apps/linpack/), I'm topping around 14MFLOPS
for the Beagleboard-XM at 1GHz which is very far from what other
device such as the Nexus achieve. I though that Sitara technology at
1GHz should be in some good conditions compared to the other
alternatives...
Has anyone managed to go higher on its Beagleboard-XM? Obviously,
frying up the chip with mpurate=2000 followed by a double explosion of
the TPS and the memory doesn't count!
The whole point of benchmarking is to use the same method as
everybody!!! If you use C, you are changing everything.
I see two basic areas of improvements: obvious kernel frequency, and
compilation flag of Android. I do think that I have the right Neon
flags during the compilation of Android.
Taking a look at the number against Snapdragon, my feeling is that I
don't use 128 bit. And I have downloaded various Android images
including from TI website and they give the same kind of performance.
It's probably a question of Android gcc/toolchain optimisation.
I think that it would make some sense for TI to take a look. Perhaps
somebody at tI has already done some work about this. Because right
now, TI looks completely ridiculous against Freescale!
Taking a look at the number against Snapdragon, my feeling is that I
don't use 128 bit. And I have downloaded various Android images
including from TI website and they give the same kind of performance.
Snapdragon probably has a pipelined VFP unit, unlike the A8. It makes
a huge difference. Try running the same test on an A9 and compare.
It's an interesting point but my initial question was more "is there
anything more to do in software to improve the situation on
Beagleboard-XM?". Reading between the lines, I guess that no. In other
words, there is no crazy GCC optimization in Angstrom/AIOS OE-based OS
that could be ported to Android toolchain to get 128 bit in SIMD and
then improve the number? Or it's already at 128 bit - then how to know
and check?
G2 <grego...@gentil.com> writes:
> Taking a look at the number against Snapdragon, my feeling is that I
> don't use 128 bit. And I have downloaded various Android images
> including from TI website and they give the same kind of performance.
Snapdragon probably has a pipelined VFP unit, unlike the A8. It makes
a huge difference. Try running the same test on an A9 and compare.
It's an interesting point but my initial question was more "is there
anything more to do in software to improve the situation on
Beagleboard-XM?". Reading between the lines, I guess that no. In other
words, there is no crazy GCC optimization in Angstrom/AIOS OE-based OS
that could be ported to Android toolchain to get 128 bit in SIMD and
then improve the number? Or it's already at 128 bit - then how to know
and check?
To improve performance of specific pieces of code, you hand-optimise
them in assembler. If you don't want to do it yourself, you hire me
to do it.
