[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 
anyway :)
> 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 
be changed?


Reply to: