DragonFly users List (threaded) for 2006-12
DragonFly BSD
DragonFly users List (threaded) for 2006-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Idle question about multi-core processors

From: "Dmitri Nikulin" <dnikulin@xxxxxxxxx>
Date: Sat, 2 Dec 2006 01:35:27 +1100

On 12/1/06, walt <wa1ter@myrealbox.com> wrote:
[I confess, I'm not sure if this question is off-topic or not.]

I just read this blurb in an e-newsletter:

Advanced Micro Devices Inc. (AMD) launched a motherboard with four cores
on Thursday, targeting gaming enthusiasts in an effort to keep pace with
the release of quad-core chips by rival Intel Corp.

This is what confuses me. Extremely few games actually multithread usefully at all (such that even two cores are likely to get a decent workout), and incidentally I find most "gaming enthusiasts" (based on a sample of most of the people I know) are either in first-person shooters or World of Warcraft (which seems to have ensnared more people than any pursuit mankind has ever undertaken), neither of which even seem to stress perfectly average single core processors. In fact, the only game I've explicitly heard boast proper multi-threading is Oblivion, and I extensively verified that on my X2 4400+ with no issue.

Even Spore, which many know to be one of the most [excessively]
high-tech games of the present, was demonstrated on a regular laptop.

Now, if "gaming enthusiasts" prefer to run multiple copies of games at
the same time, then they're likely to make gains - except that this is
entirely impractical with single video cards. Heck, do most Windows
drivers even scale to multiple processors properly? I'd rather not
think about it.

In any case, it looks to me like the mass-market may be supporting SMP
mobo's much sooner than I suspected.  And, I suspect that DragonFly may
provide much better performance on SMP hardware than many other OS's.

True, but it's reasonable to expect Linux will pretty much always be ahead in pure performance just because it has entire armies devoted to fine-tuning everything. And since it's already known to scale to many hundreds of processors fine, a pitiful number like 4 is no issue. DragonFly currently still has way too much Giant Locking to really benefit in kernel-land.

My question (at last):  anyone care to provide a stream-of-consciousness
response to this post?

My personal attitude is not to care about hardware or even operating systems. Pick a development platform (for me, recently, Python and sometimes Java) that gives you the flexibility to support whatever hardware/OS combinations you consider reasonable, and avoid tying yourself to any particular platform, even those that just won't go away like Linux and Windows. For us developers, it's all about making sure our efforts are not wasted.

Similarly, what I'd really like from DragonFly is to become a
*general* user-mode kernel (like Inferno), not just a
DragonFly-on-DragonFly kernel. I can see great value in this kind of
"simple virtualization", and it's entirely reasonable to want to run
DragonFly as a clustering kernel on top of a much more ported and
hardware-supporting base kernel like Linux or NetBSD. If the userland
kernel could be 100% CPU-agnostic (which is a lot of work, but
entirely possible) then DragonFly could run on anything any compatible
kernel runs on, and if that includes Linux and NetBSD, that basically
translates into almost every machine any of us will ever see. This
neatly makes DragonFly much more flexible and relevant, greatly
reducing its barrier to entry (i.e. finding hardware it runs on, and
then possibly enduring long reconfiguration cycles to make it tolerate
the hardware quirks). We could end up with a situation where DragonFly
is installed alongside vim and python in an "aptitude" invocation, or
via pkgsrc. It's entirely reasonable to leverage the best parts of
other platforms, instead of trying to replace them entirely.

Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia

email: dnikulin@gmail.com

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