Re: armelfp: new architecture name for an armel variant
On Thursday 08 July 2010 14:06:58 Guillem Jover wrote:
> Actually, this only seems to me to indicate the option that Aurelien
> was mentioning (building few core packages with softfp) should be strongly
> considered instead of adding a whole new architecture, which didn't look
> had been properly explored from the initial mail?
The two eabis are incompatible right now -which means it might need tons of
work -or not, it might be trivial like a 2-liner patch, I don't know- to have
both work on a single installation. Even if that were so though, there still
is the point of actually building stuff _using_ hard and not softfp.
Otherwise, we still end up losing precious cpu cycles. I remind you that
softfp vs hardfp wastes ~20 cycles PER function call -when the function uses
floating point arguments that is.
> Personally, before any further discussion I'd like to see some numbers
> with core libraries (libc, libgcc, libgmp, libatlas? etc) built with
> softfp, which eventually might be able to switch to use the hwcaps
> infrastructure in a similar way as how packages like libc6-i686 are
for softfp, try ubuntu (karmic/lucid, etc). There is no other hardfp-built
distro that I know of -of course, distros like Gentoo and OpenEmbedded have
provided support for this quite longer, but they are different in nature and
goals of course. Even now, libc arch specific optimizations -like libc6-i686
that you mentioned- are undocumented, very few packages actually provide
support for them, and in short, software ends up totally unoptimized for no
good reason. It might be ok on a C2D or a Phenom X4 cpu where one can waste
cycles, but it makes all the difference on a low-end cpu like an ARM. It might
make the difference between playable HD video or not, for example. And I
personally don't have the luxury to wait for this to be implemented glibc-side
-given its track record.
> Adding a new (official) architecture variant is a huge overhead for
> everyone, it implies adding new porter boxes, patching packages (but
> hopefully not many) to handle the new arch, having someone handle the
> build daemons, porters to handle arch specific issues (which arguably
> should be minimal given the semblance with armel, but still), more mirror
> space, user confusion due to the incompatibility of the binaries that
> might run on the same hardware, and I'm probably forgetting others. The
> lpia is a great example of an architecture variant that was a mistake,
> and should haver never been created.
It doesn't have to be official right from the start, we just have to decide
names and triplets. I can do the building here and provide a working port as I
have the cpu power (9 EfikaMX/iMX515 systems and more coming soon), so I am
quite prepared to do this. If the system proves to be worthy it could be
adopted by Debian itself. But in the meantime, it will have proved its use to
me -and Genesi of course- getting an extra 30% with no hardware redesign is
not something to sneer at -and that's all software optimization is all about
> If the arm porters decide afterall that they want something like armelfp
> anyway, then of course I'll be glad to add the architecture name to dpkg,
> but I'd first try to exhaust other alternatives with way less overhead.
Would you suggest the changes necessary to dpkg regardless? Which files should