Re: How about sparcv7, sparcv8, and sparcv9 binary debian packages? [Was Re: improving ssh2 performance on SPARCv8/SPARCv9 systems]

[Andrew Sharp <andy@netfall.com>]

Andrew Sharp wrote:
> 
> 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

hierarchies ... I think it works ...

> 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

hierarchy

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

[sheesh]

a


-- 
To UNSUBSCRIBE, email to debian-sparc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org