On Thu, 11 Mar 2010 11:46:57 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> On Wed, Mar 10, 2010 at 9:52 PM, Neil Williams <codehelp@debian.org> wrote:
> > *Precisely* what changes do you need for that "architecture" - is it
> > really a different architecture from armel? (Answers to debian-embedded
> > please.)
>
> hi neil,
Please keep this on debian-embedded rather than debian-devel - it has
very little to do with typical Debian development processes.
> the OP, jonathon wilson (cc'd) wanted to recompile to take advantage
> of ARM926EJ-S features and also OMAP3530 features (cortex A8); i want
> to recompile to take advantage of S5PC100 (cortex A8) features.
Which are? Has anyone measured the differences and identified which
kinds of processes and actions have no impact?
> [apparently there's quite a significant speed improvement to be had
> because the cortex A8 architecture was actually done by a different
> company as a from-ground-up reimplementation of ARM instruction set,
> that ARM then bought up when the investor pulled out]
Only certain packages - it can't be worth the pain to do that for all
packages. A handful at most - those which are speed-critical or highly
dependent on CPU throughput (like codecs).
("apparently" doesn't sound that sure of the detail - before you
consider spending months rebuilding packages for no benefit, find out
the detail and TEST.)
> based on what you've said, would you advise jonathon that it be
> better to target the "worst offender" packages and where the most
> bang-per-buck can be had, for example recompiling the linux kernel to
> take advantage of processor-specific optimisations i can think of as
> being the most obvious one.
Highly targeted - i.e. for every 1,000 packages considered, 3 should be
considered for rebuilds and even then, you'll probably test and drop
one of those. (More than 3 if you have a skewed package selection, e.g.
with a lot of video/codec packages ala set-top boxes.)
When building, you don't want to consider cross-building either. The
point is to reduce the number of packages to the point where you can
build the ones you need - and test them - natively. Change the package
version, add and omit compiler flags, build several versions and TEST,
test, test, test.
All the rest of the packages can then come from Emdebian Grip or
standard Debian. (Grip makes no effort to change compiled binaries, the
binary in Grip is identical to the binary in Debian.)
The standard way of rebuilding lots of packages is to create your own
version of the Debian buildd queue. You create a chroot, you nobble the
compiler in the chroot to set the flags you want - or you individually
change each package to set the flags you want. Then use tools like
schroot or buildd or pbuilder to build stuff within the chroot -
natively on the armel device.
This is particularly relevant for the kernel which has lots and lots of
options that will have a bigger impact on overall performance compared
to the effects of specific compiler flags. As you're recompiling the
kernel anyway, you should look at kernel configuration and optimise
that BEFORE testing the effect of compiler flags.
There's no standard tool to do all of this because it depends on what
you are trying to achieve each time and because, in most situations,
the end results can be marginal anyway.
Test with standard native builds with manual tweaks. If you find that
some tweaks are useful and have measurable impact on performance,
*then* look at how those tweaks can be preserved into updated versions
of the relevant packages.
There's no point inventing a whole system in advance of whether you
know if it's going to be worth the effort.
That was the lesson of Emdebian Crush - it was too much work to be
sustained.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgp44MeAgMoZv.pgp
Description: PGP signature