Re: Where could I upload x32 port bootstrap?
Adam Borowski wrote:
>On Fri, Nov 09, 2012 at 11:27:20PM +0100, Marco d'Itri wrote:
>> On Nov 09, Daniel Schepler <email@example.com> wrote:
>> > I've asked a couple people in private mail about this, and haven't
>> > gotten any answer, so I thought I'd ask here for ideas. Where would
>> > be a good place to upload what I have so far from bootstrapping an x32
>> > port of Debian?
>> Nowhere, until we decide if and how we want to use x32.
>> IIRC there was some agreement that if we decide to support x32 it should
>> be as a partial architecture.
>That'd make it mostly worthless. If you need to co-install amd64 packages
>on the same system (but not physical machine!), memory gains are gone.
>On the other hand, x32 can be pretty nice in, for example, vserver
>situations: you have tens of fast CPU- and memory-efficient vservers while
>you have an option of adding an amd64 one.
>So, x32 would need to have all of the userspace. Using an amd64 kernel is
>no different from an i386 system: currently done via a duplicate package,
>could be done via a minimal use of multiarch. If this is what you mean by
>"partial architecture", then we're not in disagreement.
>Speed gains are far better than armel->armhf, at least for i386. Gains
>compared to amd64 are limited to pointer-heavy code, said to be up to 30%.
>If Daniel could upload his work somewhere, we'd be able to test this
>ourselves instead of relying on some random benchmarks.
*If* we want to include x32, it's worth describing it and
understanding the potential benefits properly and getting some
benchmarks. There's been some work in Ubuntu on the benchmarking front
(as I saw mentioned in a session at UDS last week), which should be
worth looking at. Hmmm, can't find any direct links to them,
though. :-( Maybe somebody else can fill in here?
To explain for people who may not know: the benefit of x32 is that it
gives a non-shit 32-bit x86 ABI. i386 is *awful* as a processor to
target for many reasons, horrendously starved of registers. amd64
(x86_64/x64) fixed this *and* added 64-bit support, which helped a
lot. amd64 typically gives much better performance on processor-heavy
workloads than i386 due to the increased register space, but this
improved is offset a little by the cost of the larger pointers taking
more cache space. x32 is an attempt to get the benefit of the better
register set without killing cache so much.
So, where would x32 fit in the *long* run? Ideally (IMHO) it would be
a partial architecture that would replace most of amd64. Similarly to
powerpc(64) and sparc(64), the ideal setup for most users is to have
* 64-bit capable kernel and ABI (so things like LFS work)
* most of userspace 32-bit (who needs a 32-bit version of ls??)
* 64-bit libs and programs for those places where 32-bit address
space won't cut it (databases, iceweasel :-))
The partial architecture idea is hardly new, and it's one of the
places where multi-arch can give us really big advantages once we
get everything using it.
Downsides: the usual work involved in getting a new port going.
So, should we do it?
Steve McIntyre, Cambridge, UK. firstname.lastname@example.org
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews