FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-06-2010, 05:30 PM
Hector Oron
 
Default armelfp: new architecture name for an armel variant

Dear armel porters,

I am writting this letter to you by out concern of having to pick
up a name for a new armel architecture variant optimized for hard
floating point, instead soft floating point.

Konstantinos (and I shall be also supporting him) is willing to
maintain a new architecture for Debian at least in an unofficial way
at debian-ports.org.

Before this email, we have crossed, also with Aurelien Jarno, some
private emails which I'll be quoting here for better understanding:

> What is this new architecture? Is there a huge difference compared to
> building only a few libraries with hardfp?

Konstantinos has done a proof of concept built for Ubuntu Karmic and
he has got some interesting results [1]

" There are 3 ABIs in armel right now, regarding the use of the fpu: a) soft (no
fpu used, all fpu math is done software only, using libgcc fallback
functions), b) softfp (the fpu is used, but function arguments are passed
through the integer registers and not the fpu hardware registeres, this
results in unnecessary register moves for every function call that uses
floating point argumetns, c) hardfp, argument passing is properly done using
the fpu registers directly. The result is estimated to save 20 CPU cycles per
function call. Not something to ignore esp. given the embedded nature of ARM
where every cycle is important.

These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}. Softfp
is the default in pretty much every distro out there (incl. Ubuntu, Debian,
etc). Only some OpenEmbedded builds have enabled hardfp, but these are too
specialized.

Don't ask me why this was so, I don't know the historical reasons for having
this behaviour in ARM cpus. While binaries built using (a) will run on each of
the two other ABIs, softfp and hardfp are incompatible with each other -I know
I tried and I had it verified by ARM engineers as well.

So, in order to test hardfp, one has to build a complete base distro. In order
to have a basic karmic image to test and compare on my efikamx, I had to
rebuild ~4k packages from scratch. The result is, not surprisingly, quite
faster than the default Ubuntu karmic installation on the system, some
preliminary results gave me 20-25% speed increase on exactly the same
software/hardware configuration (eg. glxgears on software mesa reports 145 fps
vs 120 fps). The gain is bound to be bigger or smaller depending on the app
and if it does lots of calls of functions with float/double arguments (which
is of course the case with mesa and 3d).

The only drawback was that I had to use the CodeSourcery compiler, which I
built from source and packaged as a replacement gcc package, which I used to
build everything. The reason is that neither the default Ubuntu nor the Debian
gcc compilers support hardfp -yet, at least.

So... here is the story so far. I now have 9 efikamx systems here, waiting to
be used as a buildd cluster, but I have wanna-build which just busts my balls
and just won't install. I asked the Debian buildd guys, and they just
confirmed that there is neither documentation nor enough testing outside the
Debian default buildd systems. I also considered soyuz (the Ubuntu
alternative) but it's still not available as standalone -it needs the complete
Launchpad to work properly, at least now.

So, any ideas, beside building 20k packages by hand? "
-- Konstantinos

I think you should be aware Konstantinos is a retired DD and he might
enroll again Debian via NM if posible.

" That would be nice to compare hardfp with softfp, and to do it from the
user experience point of view. Of course it is always possible to find a
software that benefits greatly the change, like glxgears.

hardfp has the main disadvantage that it is not compatible with CPU
without FPU.

On the other hand, one can imagine providing only a set of optimized
softfp libraries in addition to the default soft one, that are selected
at runtime. "
-- Aurelien

Aurelien also adds to Konstantinos suggestion:

" > Personally, I think the best choice would be to go for something
like armelfp
> (who knows, armeb might have the same dilemma in the future)."
-- Konstantinos

" This really has to be decided and agreed *before* we create an archive
on debian-ports.org and you start building packages. If that changes, we
have to create a new archive, and everything has to be rebuilt from
scratch. "

So, now, it is up to you, dear armel porters if we can have an
official name scheme for such architecture to be added to dpkg
architecture tables.


*`armelfp' was suggested*, so what would you think of having such
architecture name for armel+hardfp port?


I would also like to comment that genesi-usa has been kind enough to
provide with hardware (EfikaMX [2]) to some of the leading people on
Debian projects as Live, Emdebian and Edu. If you want to work on the
port, there might be a board for you too. Most needed bit to have
official Debian support for such hardware would be a mainlined kernel,
which current is built over Pegatron SDK which builds upon Freescale
SDK. If you are willing to do kernel work for EfikaMX (i.MX515 CPU)
let us know.

Best Regards,

[1] http://www.powerdeveloper.org/forums/viewtopic.php?p=13609
[2] http://www.genesi-usa.com/products/efika
--
Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTimoAsV_lxMTplp3aQv9vDM5Gx-31tU7pqnI6k-e@mail.gmail.com">http://lists.debian.org/AANLkTimoAsV_lxMTplp3aQv9vDM5Gx-31tU7pqnI6k-e@mail.gmail.com
 
Old 07-06-2010, 05:43 PM
Konstantinos Margaritis
 
Default armelfp: new architecture name for an armel variant

On Tuesday 06 July 2010 20:30:13 Hector Oron wrote:
...
> some preliminary results gave me 20-25% speed increase on exactly the same
> software/hardware configuration (eg. glxgears on software mesa reports 145
> fps vs 120 fps).

Just one comment, some more benchmarking [1] revealed ~35% speed gain in
floating point intensive operations. So, please consider that when you take
things into account.

Konstantinos

[1] http://www.powerdeveloper.org/forums/viewtopic.php?p=13602#13602


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007062043.18285.markos@genesi-usa.com">http://lists.debian.org/201007062043.18285.markos@genesi-usa.com
 
Old 07-06-2010, 05:45 PM
Paul Brook
 
Default armelfp: new architecture name for an armel variant

A couple of inaccuracies:

> These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}.
> Softfp is the default in pretty much every distro out there (incl. Ubuntu,
> Debian, etc). Only some OpenEmbedded builds have enabled hardfp, but these
> are too specialized.

Debian is pure soft-float (i.e. -mfloat-abi=soft).

> Don't ask me why this was so, I don't know the historical reasons for
> having this behaviour in ARM cpus. While binaries built using (a) will run
> on each of the two other ABIs, softfp and hardfp are incompatible with
> each other -I know I tried and I had it verified by ARM engineers as well.

-mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and
libraries can be freely mixed). Obviously softfp code will will only work on a
CPU with an FPU, but that's not different to (say) armv5 v.s. armv6 or vfpv2
v.s. vfpv3.

-mfloat-abi=hard is not compatible with either of the other -mfloat-abi
options.

Paul


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007061845.34312.paul@codesourcery.com">http://lists.debian.org/201007061845.34312.paul@codesourcery.com
 
Old 07-06-2010, 06:07 PM
Konstantinos Margaritis
 
Default armelfp: new architecture name for an armel variant

On Tuesday 06 July 2010 20:45:33 Paul Brook wrote:
> Debian is pure soft-float (i.e. -mfloat-abi=soft).

Right, all the more reason for a new flavour then

> -mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and
> libraries can be freely mixed). Obviously softfp code will will only work
> on a CPU with an FPU, but that's not different to (say) armv5 v.s. armv6
> or vfpv2 v.s. vfpv3.
>
> -mfloat-abi=hard is not compatible with either of the other -mfloat-abi
> options.

Hm, true, my mistake. Still, now with A8 and A9 cores, software is
underoptimized even with softfp. Hence the request for a new flavour.

Regards

Konstantinos


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007062107.10259.markos@genesi-usa.com">http://lists.debian.org/201007062107.10259.markos@genesi-usa.com
 
Old 07-08-2010, 11:06 AM
Guillem Jover
 
Default armelfp: new architecture name for an armel variant

Hi!

On Tue, 2010-07-06 at 21:07:10 +0300, Konstantinos Margaritis wrote:
> On Tuesday 06 July 2010 20:45:33 Paul Brook wrote:
> > Debian is pure soft-float (i.e. -mfloat-abi=soft).
>
> Right, all the more reason for a new flavour then

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?

> > -mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and
> > libraries can be freely mixed). Obviously softfp code will will only work
> > on a CPU with an FPU, but that's not different to (say) armv5 v.s. armv6
> > or vfpv2 v.s. vfpv3.
> >
> > -mfloat-abi=hard is not compatible with either of the other -mfloat-abi
> > options.
>
> Hm, true, my mistake. Still, now with A8 and A9 cores, software is
> underoptimized even with softfp. Hence the request for a new flavour.

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.

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.

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.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100708110658.GA20823@gaara.hadrons.org">http://lists.debian.org/20100708110658.GA20823@gaara.hadrons.org
 
Old 07-08-2010, 12:38 PM
Konstantinos Margaritis
 
Default 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?

Konstantinos


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007081538.03755.markos@genesi-usa.com">http://lists.debian.org/201007081538.03755.markos@genesi-usa.com
 
Old 07-09-2010, 02:28 PM
Loïc Minier
 
Default armelfp: new architecture name for an armel variant

On Thu, Jul 08, 2010, Guillem Jover wrote:
> The
> lpia is a great example of an architecture variant that was a mistake,
> and should haver never been created.

This is a bit oversimplified; when lpia was created, there were
proposals to diverge the x86 ISA. These didn't happen though, and I
agree that the end result wasn't worth the pain.

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100709142817.GB14789@bee.dooz.org">http://lists.debian.org/20100709142817.GB14789@bee.dooz.org
 
Old 07-13-2010, 01:06 PM
Riku Voipio
 
Default armelfp: new architecture name for an armel variant

On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote:
> 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.

The key limitation with hwcap approach is that it only extends to shared
libraries. Optimized binaries and plugins cannot be provided with hwcaps.
Things like libc-i686 are also problematic for endusers. How do I
quickly install all 686 optimized versions of libraries I already have?

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

Adding a new arch creates a big overhead for *selected* people, rather than
everyone - most packagers in debian are unaffected. Multiple libraries
is not exactly zero-effort either, there could easily be hundreds libraries
we could want optimized. That is if we want to provide a *good* service
to users with VFP's rather than a lipservice. And we still wouldn't have
a vfp version of quake2.

> The lpia is a great example of an architecture variant that was a
> mistake, and should haver never been created.

LPIA was mainly a issue since people used it as "if arch=lpia then build
mobile ui". That prevented users from installing full versions of software
or trying mobile UI's in regular i386 installations.

If dpkg had subarchitecture support, lpia wouldn't have been as big
a issue. Ubuntu decided to shortcut and not add support for compatible
subarchs in dpkg, and the result was what it always is when people make
shortcuts...

Subarchs could also be useful if we wanted to build softfp abi compatible
armv6/armv7 armel builds of the whole debian repository. Of course we could do
builds without subarchs, but then users would be unable distinguish which
installed packages are for which cpu, and providing that via debian infra
would not be possible.

But the key difference with lpia and hardfloat armel is that they are not binary
compatible. And if we use it as a opportunity to target armv7+, do not really
share much of hardware either.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100713130615.GA14566@afflict.kos.to">http://lists.debian.org/20100713130615.GA14566@afflict.kos.to
 
Old 07-15-2010, 04:48 PM
Aurelien Jarno
 
Default armelfp: new architecture name for an armel variant

Riku Voipio a écrit :
> On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote:
>> 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.
>
> The key limitation with hwcap approach is that it only extends to shared
> libraries. Optimized binaries and plugins cannot be provided with hwcaps.
> Things like libc-i686 are also problematic for endusers. How do I
> quickly install all 686 optimized versions of libraries I already have?
>

Note that the new alternative to hwcap is called "multiarch" in the GNU
libc (something totally different than "multiarch" in Debian). It allows
to provide different versions of a given symbol using an IFUNC symbol
type. This will be resolved by the dynamic loader during relocation
depending on the hardware characteristics.

This avoid building multiple version of the same software (but still
multiple versions of a given function), and to introduce more
granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc).

Currently only x86, x86_64, ia64, powerpc and sparc are supported, but
it should not be difficult to add support for more architectures.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C3F3BEB.3030009@aurel32.net">http://lists.debian.org/4C3F3BEB.3030009@aurel32.net
 
Old 07-15-2010, 05:06 PM
Konstantinos Margaritis
 
Default armelfp: new architecture name for an armel variant

On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> Note that the new alternative to hwcap is called "multiarch" in the GNU
> libc (something totally different than "multiarch" in Debian). It allows
> to provide different versions of a given symbol using an IFUNC symbol
> type. This will be resolved by the dynamic loader during relocation
> depending on the hardware characteristics.
>
> This avoid building multiple version of the same software (but still
> multiple versions of a given function), and to introduce more
> granularity (e.g. on x86 SSE, SSE2, SSE3, SSSE4.2, AVX, etc).

So, in essence an application/library can include in the same binary multiple
versions of the same function and the system picks one depending on the
current cpu capabilities? So things like autodetecting SSE/Altivec, etc are
not needed anymore?

> Currently only x86, x86_64, ia64, powerpc and sparc are supported, but
> it should not be difficult to add support for more architectures.

I'm interested in that, is it documented somewhere? ( I know the old hwcap was
not at all, unless one wanted to read half of glibc source code).

Regards

Konstantinos


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007152006.42846.markos@genesi-usa.com">http://lists.debian.org/201007152006.42846.markos@genesi-usa.com
 

Thread Tools




All times are GMT. The time now is 11:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org