implemented features (Re: Decision time....)

[km b]

On 04 Jun 2007 08:45:18 GMT, Rahul Siddharthan <rsidd120 at gmail.com> wrote:
I found this comment on Dmitri's blog possibly unfair, but somewhat
reflecting my own perception as well:
http://spetskod.blogspot.com/2007/05/immature-optimization.html#comment-8539868674748140994
DragonFly was forked from FreeBSD-4 because of dissatisfaction with
FreeBSD 5's approach to many things, including SMP.  But nothing
visible to the user seems completed yet, especially not SMP.  And it
looks like it won't be completed for 2.0 either.
Gr8 you're really far sighted.

Today, nearly any new machine one buys will have at least 2 CPU cores,
perhaps 4 or more.
Also, nearly any new machine, whether AMD or Intel, will be 64-bit.
On my own code (computational biology), using gcc, 32-bit binaries are
50% slower than 64-bit binaries.  (This is true of both gcc3 and gcc4.
In fact, gcc 64-bit binaries are faster than 64-bit binaries generated
by the Sun Studio compilers on amd64.)  That sort of speed difference
is not trivial for the sort of work I do.
Please back your claims with empirical results. Please don't
generalize without finding out why 32-bit binaries are 50% slower than
64-bit binaries. Have you measured against pure 32-bit environment vs
pur 64-bit environment or just executing 32-bit binaries under 64-bit
environment. Have you measured the effect on the cache in different
environments (if you are using FreeBSD you can do so using PMC).
So on a new machine I would really want to run a 64-bit, SMP OS.
DragonFly is ruled out on both counts.
DragonFly is an SMP OS. 64-bit is desirable if you want to utilize
more than 4G address space.
If one views DragonFly as a pet research project of Matt, Simon and
others, this is fine.  But if it is to be a serious alternative to
FreeBSD or other systems, shouldn't there be some focus on near-term
goals that are actually useful to regular users, rather than ambitious
ideas like a brand-new filesystem?  It seems to me that SMP and 64-bit
support should be the first priorities.
Any near term "make it work" goals would make it another "hack it
yourself" os. You can use linux.
If DragonFly were usable to me, I would be able to contribute to some
things -- pkgsrc, testing device drivers -- though not to kernel-level
stuff.  But at this point, I can't even run DragonFly on a new
computer without crippling myself.
Go through the pain of trying it first and getting some help, where
you get stuck. We'll make it work.
Rahul
kmb

--
Something is wrong up on cloud # 9!