Re: How about sparcv7, sparcv8, and sparcv9 binary debian packages? [Was Re: improving ssh2 performance on SPARCv8/SPARCv9 systems]
Ben Collins wrote:
>
> On Tue, Apr 09, 2002 at 12:07:41PM +0200, Christian J?nsson wrote:
> > On Tue, Apr 09, 2002 at 09:26:38AM +0000, Wilmer van der Gaast wrote:
> > > Christian J?nsson@lists.debian-sparc@Tue, 9 Apr 2002 10:32:22 +0200:
> > > > Come to think of it, has there been any discussions of having, say,
> > > > sparcv7, sparcv8, and sparcv9 binary debian packages instead of just
> > > > sparc ones? Well, sparcv7 would be sparcv7, right?
> > > >
> > > That'd be a huuuuuge waste of mirror space, I think. Just look how large
> > > the archives are already. Some CPU-critical packages can be recompiled
> > > and put on a separate apt repository, but creating two more
> > > architectures for speed's sake would be a waste.
> >
> > Oh, I wasn't thinking of the *entire* release, rather, as you put it,
> > speed critical packages. I would think, though, that there are quite a
> > few with reasonable speed increase. I'm not sure, but it might be
> > v7->v8 gives more than v8->v9, that's more of 32->64 bit, right?
>
> Actually, I think v7->v8plus is the right way to go. To answer someone's
> question, post woody I am going to start looking at this in some detail.
>
> I have a few options:
>
> 1) Just make the sparc compiler default to v8, which will pretty much
> kill off sun4c support. However, this has _huge_ benefits for
> UltraSPARC and Sun4m (I noticed big improvements with libssl, libc6
> and apache2 recompiled with v8 opts on a U30).
>
> 2) Create a new sparcv9 dist that is compiled with v8plus or v9
> optimizations. This would provide the same benefit as above (and no,
> v9 does not mean 64bit), but cost Debian and mirrors about 3gigs in
> extra archive space (on top of the close to 30 gigs it takes now).
> IMO, v7 isn't worth wasting 3gigs over.
>
> 3) Provide optimized packages. This isn't an option right now, until
> dpkg can handle versioned virtual packages (e.g. if something
> "Depends: libssl0.9.6 (>= 0.9.6-1)", then a package named
> libssl0.9.6-v8plus would not satisfy that dependency).
>
> > However, there's also the (upcoming?) possibility to configure for
> > sparcv9-*, that'll be interesting when it hits the masses :-)
> >
> > > (A similar discussion about i686-optimized packages has been on Debian
> > > Planet <http://www.debianplanet.org/> before..)
> >
> > I figured, it's exactly the same issues we're talking about here, right?
>
> Not really. We don't have 4million whining i486 users around (probably
> more like 4000 sun4c users, and sun users are way less whiny :)
>
> If I kill off v7 support after woody release, then sun4c users will
> still have roughly 2 years of support left for a stable dist from
> Debian.
Solaris handles this with library heirachies. I've heard some hair
pulling about how "ugly" this is, but I don't think it works pretty
good. Just look at the quandry that we debianers are in over this.
The library linker has a bit of extra code to hunt down the correct
library to link in based on the machine type. Of course, they are
focused on selling hardware, so they have cast off support for v7
completely, IIRC.
And there is more than just v[789], there are other sparcs as well,
like the fujitsus, and help me out here hardware types, but weren't
there a few external FPUs back in the v8 days? The library heiarchy
idea would sure allow on-the-fly support of more stuff, like the VIS
of v9 and so forth. Did US3 add any user instructions?
a
--
To UNSUBSCRIBE, email to debian-sparc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: