Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Aug 2000 20:30:41 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        rob@controlq.com (Robert S. Sciuk)
Cc:        freebsd-sparc@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG
Subject:   Re: your mail
Message-ID:  <200008172030.NAA19336@usr06.primenet.com>
In-Reply-To: <Pine.BSF.4.21.0008171016050.45559-100000@schizo.controlq.com> from "Robert S. Sciuk" at Aug 17, 2000 10:35:33 AM

next in thread | previous in thread | raw e-mail | index | archive | help
> > On Wed, Aug 16, 2000 at 12:57:24PM -0700, David DeTinne wrote:
> > > Is the sparc port really dead?
> > > 
> > > I have tried the other BSD's and from an average users
> > > standpoint FreeBSD is the best (my opinion)
> 
> To play devil's advocate, briefly ...
> 
> Perhaps we should examine just why FreeBSD is `best'.  As I understand it,
> the limited architectures supported has maximized talent and effort into
> making the intel platform work REALLY well, added stability, content,
> performance and functionality.
> 
> If FreeBSD migrates to additional architectures, how much of its
> `goodness' will translate directly to other platforms??  Moreover, how
> much future effort and talent will be diverted into porting efforts rather
> than single platform perfection??  One must always trade off optimal
> platform performance for the sake of portability!

Doing a port to another architecture is pretty trivial.  I had
a Motorolla PowerStack system running a PPC port of FreeBSD up
to single user mode back in 1997.  It took less than two months,
and the biggest obstacle was waiting for Motorolla to ship the
PPCBug SDK and documentation to me (I had to pay for it twice,
since they screwed up the first shipment).

The biggest obstacle, historically, has been isolating the
architecture dependent bits in the FreeBSD source tree.  This
has become much less of a problem, since the Alpha port has
become mainstreamed, though there are still some pieces that
depend on "alpha" vs. "!alpha", instad of on "ARCH", and there
are not C versions of everything that could be C instead of
assembly code.

Going from another BSD to FreeBSD self-hosted on SPARC has got
to be a damn sight easier than going from AIX to FreeBSD
self-hosted on a PPC platform with PReP but not CHiRP support
and a non-standard ias opposed to OpenBoot boot monitor.


> I'd love FreeBSD on Sparc, and PA-RISC for that matter -- just not at the
> expense of the single best Intel based OS I've yet to encounter!!!  I am
> happy with OpenBSD and NetBSD (thought neither one is on PA-RISC yet).

PA-RISC is terribly dead, but since the MACH port and the OSKit
work at the University of Utah, if you happened to have one of
these things lying around, you could do the work, probably in a
pretty short time frame, if you started with OSKit or another
UNIX-like system as the base.

The biggest barrier to PA-RISC is hardware documentation.


> I look at the scalability efforts going on in the FreeBSD kernel as a case
> in point, removing the GBL and threading and wonder just how much of that
> will translate directly to other architectures??

A lot of it.

> Would this effort have started at all if the talented individuals
> working on it were busy porting to platform X??

Probably not; but you are incorrectly assuming that if work was
expended on one, that it would not be expended on the other,
since you appear to be assuming that it's the same people who
would be doing the work.

I rather seriously doubt that the set of SPARC-knowledgable people
and the set of Intel MPSpec and APIC knowledgable people has a
very large intersection.  I could probably count the people who
were _ever_ involved with FreeBSD that had this combination on
both hands, with fingers left over.


> No doubt at the end of this project, FreeBSD on Intel should beat
> the living pants off of NT and Linux on the scability side of the
> equation.

Beating Linux performance is rather trivial.

I have rather grave concerns about some of the technical
approaches being pursued in this attempt, particularly as
concerns use of kernel threads to dumb-down state machines
to the point that linear thinkers can understand them.  The
SMP scaling strategy currently looks to be limited in value
over 4 processors, which is supposedly an Intel limitation,
but which others (e.g. Sequent) have demonstrated is really
a limitation of the approach used to solve the problem.

I actually rather doubt that it will beat NT performance, since
free software projects appear to have a Roche limit over a certain
level of complexity that prevents them from doing some things.  It
has been a tendancy of many commercial companies, fearing open
source, to drive increasing complexity into IETF standards (IMO,
without technical necessity) in order to protect their shrinking
domain without having to actually confront the other commercial
companies eating into their market.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008172030.NAA19336>