Native compilation on the BeagleBoard / what distribution?

Hello everyone,

What distribution would you recommend in order to perform native on-
device compilation? I would like to avoid cross compilers whenever
possible and it looks like the board should be fast enough to run the
compiler and produce code in reasonable time.

Also, what distribution/image should I use for an embedded application
where we have absolutely no need for an X server or any kind of
graphics? We would like APT to work and maybe the dev tools (gcc - see
above).

I'm sorry if this has been asked before, but a search through the
discussion group didn't find anything relevant.

Thank you,
Razvan

The cpu is fast enough, but you'll notice soon enough that 128MB of
ram isn't going to cut it, especially when compiling things like C++
and C#. Crosscompiling is still your best bet. Systems like
OpenEmbedded make it really easy and take care of packaging and
dependencies as well.

Anyway: 'opkg update ; opkg install task-native-sdk' in angstrom will
get you a native toolchain.

Angstrom is the distribution I would recommend today, but you could
also use Ubuntu from mojo.handhelds.org. They include native gcc.

Angstrom is the distribution I would recommend today, but you could
also use Ubuntu from mojo.handhelds.org. They include native gcc.

Which won't work too well, since it lacks armv7 and neon support

drazvan wrote:

Hello everyone,

What distribution would you recommend in order to perform native on-
device compilation? I would like to avoid cross compilers whenever
possible and it looks like the board should be fast enough to run the
compiler and produce code in reasonable time.

Also, what distribution/image should I use for an embedded application
where we have absolutely no need for an X server or any kind of
graphics? We would like APT to work and maybe the dev tools (gcc - see
above).

I'm sorry if this has been asked before, but a search through the
discussion group didn't find anything relevant.

Debian sid armel. Definitely.

b.g.

Which will work even less than ubuntu, since it lacks armv5, armv6,
armv7 and neon support.You will only be able to use a tenth of the
power of the cortex (hello armv4t softfloat and slow glibc memcpy!)
unless you recompile your system, at which point you'd have to ask
your self how usefull debian is over other, already optimized distros.

> 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.

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?

your self how usefull debian is over other, already optimized distros.

Ah, the gentoo-argument.

With the stability problems seen with neon code generation in current
gcc's,
perhaps it's a good idea to keep conservative on base system? That
does not
make it impossible to compile optimized those applications/libs where
it
actually shows significant improvement of performance. Which, until
gcc
gets stable autovectorizing, is only the apps that have hand-written
assembler inner loops.

compiler flags rarely fix O(n) problems in code.

"nhippi@gmail.com" <nhippi@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.

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.

your self how usefull debian is over other, already optimized
distros.

Ah, the gentoo-argument.

With the stability problems seen with neon code generation in current
gcc's, perhaps it's a good idea to keep conservative on base system?
That does not make it impossible to compile optimized those
applications/libs where it actually shows significant improvement of
performance. Which, until gcc gets stable autovectorizing, is only the
apps that have hand-written assembler inner loops.

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.

"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?

>> 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
approximately 2x float performance increase on synthetic benchmarks
without sacrificing precision. Worse, on Cortex-A8 the VFP is less
powerful
than on armv6, yet you can't use neon for doubles...

"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.