"nhippi@gmail.com" <nhippi@gmail.com> writes:
"nhi...@gmail.com" <nhi...@gmail.com> writes:
>> > Debian sid armel. Definitely.
>> Which will work even less than ubuntu, since it lacks armv5,
>> armv6, armv7 and neon support.
> armv5, armv6, armv7 and neon support _are_ supported on Debian
> armel.
Do you mean that debian runs on ARMv7? Nobody has disputed
that. Or do you mean there are debian packages built for ARMv7?
With NEON? That seems more doubtful.
That the compilers and userland support building ARMv5 ... ARMv7,
which, I believe, is the kind of support the original poster was
interested in?
But the prebuilt packages are still for ARMv4? To get good
performance, one would thus still have to rebuild everything, and then
it might be easier to use a distribution that supports doing this more
easily.
>> You will only be able to use a tenth of the power of the cortex
> Tenth? when there is valid reasons to use OE, why do resort this
> kind of bullshit mudslinging against Debian? In exactly what real
> world benchmark is armv4l 10x slower than armv7 without
> hand-optimized assembler code?
Hand-optimised assembler exists in the real world.
And there is several ways of shipping those optimizations on Debian
packages. For example via runtime cpu selection or by providing
several versions of the library. If you have a package that runs
significantly faster when compiled faster with special flags, you can
always ask the maintainer to provide such version.
> compiler flags rarely fix O(n) problems in code.
Using the right compiler flags already gives at least 5 times faster
floating-point code for Cortex-A8. The overall speedup of any given
application depends on how much floating-point it uses.
Thats is interesting - how did you benchmark that? We measured
I compiled a simple test program (it was discussed here not long ago)
with and without -ffast-math, and compared the execution times of the
resulting executable. Hand-written NEON assembler was faster still,
of course.
approximately 2x float performance increase on synthetic benchmarks
without sacrificing precision.
How many applications really need the full precision? In many cases,
using -ffast-math is perfectly acceptable.
IIRC, debian packages use softfloat, so this is again only relevant if
things are recompiled.
Worse, on Cortex-A8 the VFP is less powerful than on armv6, yet you
can't use neon for doubles...
Yes, this is unfortunate. They say the A9 will be better in this
regard.