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

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



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.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/


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



Reply to: