On Thu, Feb 28, 2008 at 4:09 PM, Justin C. Sherrill <[EMAIL PROTECTED]> wrote: > On Wed, February 27, 2008 11:29 pm, Dmitri Nikulin wrote: > > > The benchmark at http://people.freebsd.org/~kris/scaling/os-mysql.png > > (for the full presentation, see > > http://www.freedomtc.com/pdf/7.0_Preview.pdf, that plot is on slide > > 17) indicates that FreeBSD 7 not only competes strongly with current > > Linux performance and scalability, but that DragonFly has been beaten > > even by NetBSD which came late to the SMP party. > > Minor quibble: you're pointing at benchmarks on an 8-core xeon. > Relatively uncommon hardware, though I'm sure that'll change within a year > or so.
Sure, but SMP scalability is one of the key goals of DragonFly, and for it to be beaten by NetBSD (for which this is not a major goal, and for which SMP scalability only started being worked on a year ago) is very confusing. I haven't seen it compared with 1.12, but since no huge scalability work has gone in for a long time, I doubt it would close the gap much. Even so, while 8-core Xeons are not yet common, AMD64 compatible chips are pretty much the only mass consumer chips available now, and DragonFly can still only use the 32 bit portion of that, and even then, doesn't yet scale to two cores fully, let alone the increasingly common quad cores. That falls far short of the goal to scale well for increasingly parallel systems, which continue to be picked up by Linux and now FreeBSD at an increasing rate. That's really disappointing for an operating system I originally believed would humiliate FreeBSD's SMP implementation. > > At the risk of sounding like a troll, may I ask, if FreeBSD 7 has high > > performance, high stability and remains reasonably clean and > > maintainable, doesn't that partly invalidate the reasons DragonFly was > > created? Being cleaner and more revolutionary doesn't count for much > > if the product itself doesn't serve as a compelling alternative. Maybe > > I'm just missing the point of DragonFly's development. > > There were people attracted to DragonFly early on because they were > mistreated by various folks involved with FreeBSD, but liking DragonFly > because it's not FreeBSD is not enough to build a project. > > DragonFly is not a FreeBSD replacement, nor does DragonFly require FreeBSD > to suck in order to exist. You could probably make the exact same > argument you just did but substitute in the name of another BSD, if you > are going to take the tack of "fastest benchmark so why use anything > else?". (I realize I'm oversimplifying your words.) You're right - you are oversimplifying my words. I'm only saying that, for goals which DragonFly considers groundwork, FreeBSD still matches or wins by a large margin. That includes good performance (FreeBSD wins) and stability (FreeBSD seems to be no worse off). I can't attest to the maintainability, but they seem to be doing alright, and "cleanups" get done too. So while DragonFly has a lot going for it (which I never denied), it's challenging to find a situation for which DragonFly is actually a better choice than FreeBSD. > DragonFly is oriented towards creating a single system image over multiple > networked computers on the Internet, which has never been done before. It's years off even for DragonFly. If it does one day achieve that goal, but by then other systems have advanced to the point that DragonFly isn't even compelling for a single node, why will anyone want to run it just to join a cluster? It needs some minimum user base before internet clustering becomes useful at all. That's my biggest fear regarding this project - that by the time its highest goals are achievable, the full potential of those goals will still be out of reach, perhaps forever. > FreeBSD -> run on x86 > OpenBSD -> run securely > NetBSD -> run on anything > DragonFly -> run once everywhere? > > For myself, I find DragonFly useful because it's a tight and friendly > developer community, with lots of interesting projects to do. FreeBSD > having a good mysql benchmark doesn't affect that. > > > > neglected. Again, at the risk of sounding like a troll, I'm gravely > > concerned about the growth and survival of this brilliant project in > > the face of increasing pressure from projects with much larger > > developer communities and software ecosystems. > > We've been doing pretty well, really. The number of changes and new > developers in 2007 have been on an upswing relative to 2006. (I should > know, given my digest work.) There's been enough happening that I've had > a steady 2-day buffer of things to post for a month, which has never > happened before. That's really good to hear. It's hard to tell just from mailing lists. See, my problem is, I really care about DragonFly from a very geeky perspective. I want the clever, somewhat revolutionary ideas to win and show the rest of the world how it's done. But on the other hand, Inferno was set to do that, and how relevant is that now? -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia