Native compilation on the BeagleBoard / what distribution?
drazvan
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
--
Razvan Dragomirescu
Chief Technology Office
Cayenne Graphics SRL
Koen Kooi
On 2 aug, 22:06, drazvan <razvan.dragomire...@gmail.com> 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.
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.
Jason Kridner
also use Ubuntu from mojo.handhelds.org. They include native gcc.
Koen Kooi
On 3 aug, 14:03, Jason Kridner <jkrid...@gmail.com> wrote:
> Angstrom is the distribution I would recommend today, but you could
> also use Ubuntu from mojo.handhelds.org. They include native gcc.
Bill Gatliff
> 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.
--
Bill Gatliff
bg...@billgatliff.com
Koen Kooi
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.
nhi...@gmail.com
> 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
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.
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.
Måns Rullgård
>> > 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.
--
Måns Rullgård
ma...@mansr.com
nhi...@gmail.com
On Aug 4, 11:01 pm, Måns Rullgård <m...@mansr.com> wrote:
> "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.
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.
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.
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...
Måns Rullgård
> On Aug 4, 11:01 pm, Måns Rullgård <m...@mansr.com> wrote:
>> "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.
--
Måns Rullgård
ma...@mansr.com