Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Microsoft Software Linux

Microsoft Reports OSS Unix Beats Windows XP 442 442

Mortimer.CA writes "In a weblog entry, Paul Murphy mentions a Microsoft report (40 page PDF) that in many instances FreeBSD 5.3 and Linux perform better than Windows XP SP2. The report is about MS' Singularity kernel (which does perform better than the OSS kernels by many of the metrics they use), and some future directions in OS design (as well as examination of the way things have been done in the past)." From the post: "What's noteworthy about it is that Microsoft compared Singularity to FreeBSD and Linux as well as Windows/XP - and almost every result shows Windows losing to the two Unix variants. For example, they show the number of CPU cycles needed to "create and start a process" as 1,032,000 for FreeBSD, 719,000 for Linux, and 5,376,000 for Windows/XP."
This discussion has been archived. No new comments can be posted.

Microsoft Reports OSS Unix Beats Windows XP

Comments Filter:
  • by TripMaster Monkey (862126) * on Friday November 11, 2005 @02:56PM (#14010279)

    Here's an interesting snippet I found while perusing the PDF...thought I'd share.
    On the other hand, this paper does not validate our goal of increased dependence. Measuring that aspect of a system is significantly more challenging than performance. We do not yet have results for Singularity.
    Interesting...Singularity is ostensibly supposed to be about stability, but the 44-page paper has no data on this. Kinda like saying, "Our new bulletproof vest is 40% lighter than our leading competitors, and twice as flexible. How well does it stop bullets, you ask? Sorry...we do not yet have results for that benchmark.".

    Wake me when a paper comes out about Microsoft's new stability-oriented OS that actually addresses that particular aspect of the product.
  • by CyricZ (887944) on Friday November 11, 2005 @03:00PM (#14010315)
    Singularity is a very interesting system. But that's not surprising, when you consider some of the brains behind it: Galen Hunt, Wolfram Schulte, Ulfar Erlingsson, Rebecca Isaacs, and many others who are well-known for their research.

    In twenty or so years we may look back at Microsoft Research with the same admiration we have for Bell Labs.

  • Competition (Score:1, Insightful)

    by Anonymous Coward on Friday November 11, 2005 @03:01PM (#14010322)
    Don't you love competition????

    How can you hate microsoft or *nix? We need each other so that we can constantly get better and gauge our progress. I really hope that MS can learn to live with the OSS community; it will benefit everyone, including MS.

  • by man_of_mr_e (217855) on Friday November 11, 2005 @03:02PM (#14010331)
    Well, that's sort of to be expected. Stability is not as easy to measure as other things, since you need benchmarks over a long period of time. Further, since it's still a research OS, it's likely in constant flux and doesn't have the same kind of stability hardening of a retail OS.
  • by Kickasso (210195) on Friday November 11, 2005 @03:03PM (#14010349)
    Microsoft is not Microsoft Research. Microsoft Research folks use and make free software, and in general are not ideologically bound to the parent organisation.
  • by CyricZ (887944) on Friday November 11, 2005 @03:03PM (#14010351)
    It's not so much about its ability to start thousands of processes. What is important is that it takes Windows XP five times as long as FreeBSD to create a single process, and seven times as long as Linux. That's a significant difference.

  • by Wonko42 (29194) <[ryan+slashdot] [at] []> on Friday November 11, 2005 @03:05PM (#14010368) Homepage
    I've been seeing this damn report hailed all over the Internet for the last few days as Microsoft saying Unix is better than Windows, but apparently nobody has actually read the report.

    For one thing, Windows is not slower than Unix in most of the tests. It's slower than Unix in some of the tests and faster in others. For another, these benchmark results are for low-level things like spawning processes and threads. Any programmer who knows anything about Unix and Windows will tell you that threads are cheaper in Windows and processes are cheaper in Unix, because that's how they were designed. So of course Windows is going to be slower than Unix at creating processes, and of course Unix is going to be slower than Windows at creating threads.

    The only thing worth reporting about this thing is the performance of Singularity, which looks like it's shaping up to be an excellent modern kernel.

  • by Anonymous Coward on Friday November 11, 2005 @03:10PM (#14010414)
    NT (and its latter incarnations like XP and so forth) are desgined to use threads rather than process for multi-processing/concurrency, I understood. Is Win XP less efficient in multi-threading than BSD/Linux? The history of threads in UNIX seems more later bolt-on - UNIX was designed with multi-process model, I think.

    No I didn't RTFA.
  • by yurnotsoeviltwin (891389) on Friday November 11, 2005 @03:11PM (#14010429) Homepage
    You definitely have a good point there. Everyone around here bashes Microsoft obviously, and for good reason. Their business practices can get a bit on the shady side sometimes, though they problably aren't deserving of quite the amount of hate they get around these parts. But their programming and research, particularly research, isn't that shabby, and certainly isn't "evil." Remember, M$ doesn't just sell operating systems, it makes them too, and to do that you have to have brains. I think some people around here need to give at least the engineers and researchers in Microsoft a little more respect.
  • by chris09876 (643289) on Friday November 11, 2005 @03:13PM (#14010458)
    The scenario stated in the slashdot post does show a situation where linux performs better than Windows. ...but after looking through the "performance" section of the whitepaper, it's pretty much the only case where linux is better. Windows appears to beat linux on quite a few other tests (such as memory use of a 'hello world' program, the executable size, and even some of the 'cost of basic operations' tests)
  • Re:Too Telling (Score:2, Insightful)

    by PickyH3D (680158) on Friday November 11, 2005 @03:18PM (#14010505)
    I think it's more telling that the paper shows Linux or FreeBSD as performing better in a few tests, which is the reason it was able to appear on the front page.

    I'm happy though that MS may be taking Singularity seriously. Maybe we will see their OS in 2011-2015 based on it? Unless some sort of major shift in its purpose occurs, then I would definitely jump ship from whatever I am on then, to that and I will definitely port/develop my software for the OS.

  • by Todd Knarr (15451) on Friday November 11, 2005 @03:22PM (#14010536) Homepage

    Exactly. NT got it's process model from VMS, and process creation was a very heavyweight operation. Unix, by contrast, had a very lightweight process creation operation. Hence NT needed threads to provide a faster alternative to processes, while Unix (whose processes were almost as cheap to create as NT threads) didn't really need threads for anything other than a marketing checklist (about the only thing Unix threads get you that processes don't is fully-shared address space, and I'd argue that's often more a problem than an advantage).

  • by LaughingCoder (914424) on Friday November 11, 2005 @03:23PM (#14010544)
    Sad that your comment is modded as funny. In fact what you say is insightful and probably will turn out to be true. It amazes me how most people in this forum refuse to give Microsoft credit for anything they do or have done, but they are more than willing to heap blame upon them. I believe that *overall* Microsoft has in fact been a positive force in the industry. This doesn't mean everything they have done worked out for the "common good", but I think the scale tips in that direction. And don't forget that they continue to spend lots of R&D dollars both on product development and pure research. You would think a technical audience like /. would appreciate that. To me it smacks mostly of envy and jealousy. Can't we all just get along?
  • by Wonko42 (29194) <[ryan+slashdot] [at] []> on Friday November 11, 2005 @03:24PM (#14010551) Homepage
    Yes. It's the "almost every" that I have an issue with, because it's a blatant exaggeration. I've also seen that phrasing used in several news articles about the report. But when I looked at the actual report, I saw plenty of tests where Windows actually beat Unix. I didn't bother counting, but I'd estimate that the two came out pretty evenly matched, with Unix maybe slightly ahead. In any case, no matter which one beat the other more times, these are very low-level tests. Nobody's going to notice these differences unless they're running a high-traffic server or doing some really heavy-duty computing.
  • by tqbf (59350) on Friday November 11, 2005 @03:25PM (#14010555) Homepage

    Here's the table from the paper, ranked best-worst, W=windows, F=freebsd, L=linux, S=singularity:

    Read Cycle Counter: W: 2, F: 6, L: 6, W: 2, S: 8

    ABI Call: S:87, L:437, W:627, F:878

    Thread Yield: S:394, W:753, L:906, F: 911

    2-Thread ping-pong: S:1207, W:1658, L: 4041, F: 4707

    2-Message ping-pong: S:1452, L: 5797, W: 6244, F: 13304

    Process Creation: S: 300000, L: 719000, F: 1032000, W: 5376000

    The only stat in this table that Windows trails on is process creation. And anybody who has ever ported Unix code to Win32 knows exactly why: Windows is thread-oriented, and Windows systems don't tend to use helper programs or demand-forking to get work done. Which might be why Windows beats Unix in the thread benchmarks, but not in the IPC benchmarks. On the more general benchmarks, like cycles to issue a system call, Windows falls smack in the middle --- and, again, Windows has a slightly different take on what is and isn't a system call.

    Drawing comparisons between Singularity and normal operating systems here is silly. Singularity doesn't have processes in the conventional sense; since there's no hardware dependencies on "process" creation in Singularity, IPC and forking are much faster.

    Which is why this benchmark is reasonable inside the Singularity tech report (they're trying to demonstrate that there's a major performance benefit in rethinking boundaries between programs), but totally unreasonably outside that context: these are micro-benchmarks, like the ones CISC and RISC people throw at each other, and don't describe the amount of time it takes to complete a high-level task. Time to execute a system call is meaningful only in the context of how many system calls it takes to complete the task you're measuring.

  • Re:Too Telling (Score:3, Insightful)

    by arkanes (521690) <arkanes@gmail . c om> on Friday November 11, 2005 @03:40PM (#14010687) Homepage
    Nothing that people didn't already know there - take a look at the numbers for thread operations and note how they're much, much faster than the Linux/BSD numbers. Creating a process on Windows has always been very expensive, and threads have always been fast. It's why Windows applications use threads where equivilent Unix ones fork.
  • Depends (Score:3, Insightful)

    by jd (1658) <imipak@yah[ ]com ['oo.' in gap]> on Friday November 11, 2005 @03:41PM (#14010696) Homepage Journal
    There's been a lot of work on improving the threading under Unix variants. M:N threading models, zero-copy where data structures are identical, etc. It is entirely possible, if not probable, that some cases of threading will actually be faster under some u*ix-like OS' than Windows. Because there has also been a lot of work on security models under u*ix-like OS' (role-based memory encapsulation, etc) which are inherently slooooow, there will certainly be u*ix-like OS' which are slower at starting new processes under those OS' (where you will have maximal security checks) than Windows.

    In other words, write the benchtest for the sorts of sub-category of cases that side with you, and you can make any benchmarks show what you want them to show. That's one reason they should always be viewed with a pinch of salt and a dash of vinegar, then served in newspaper.

  • by Tony Hoyle (11698) <> on Friday November 11, 2005 @03:47PM (#14010741) Homepage
    Same difference... you've still shutdown all your network services which to the users means you've had downtime. It's a reboot in all but name.
  • by Zerathdune (912589) on Friday November 11, 2005 @03:50PM (#14010765) Journal
    I loath microsoft, and I think I'm justified in that. Most of it is because of their business practices. We can't ignore the fact that they are a convicted monopolist, especially after having gotten off with little more than a slap on the wrist. It also annoys me that they buy/copy more than they innovate. they bought DOS, and based their OS's off of that for a while, and they hired out another company to make NT for them. And the constant FUD is yet another perfectly legitamite reason to hate them. The fact this is front page news is proof of that. even in this case, they aren't being entirely truthful. from TFA: So why is this interesting? Because their test methods reflect Windows internals, not Unix kernel design. There are better, faster, ways of doing these things in Unix, but these guys - among the best and brightest programmers working at Microsoft- either didn't know or didn't care. if that's honesty, I'm not surprised nobody gives them any credit.

    that said, I agree with you that they get even more shit than they deserve. Not all of their products are terrible. MS Office is actually significantly more efficient than OOo. they've done a very nice job with MSN messenger. I can't comment on Singularity, as I know next to nothing about it. I still think they're satan incarnate, but I'm willing to give credit where credit is due.

  • by LowneWulf (210110) on Friday November 11, 2005 @03:53PM (#14010792)
    I've seen talks and papers that have come out of Microsoft research, and while it may look good as a website summary, the quality of the actual projects and results varies wildly. They may talk big, but in the end, I've only ever seen a couple of projects out of MSR that were even worth talking about, and the research labs of places like IBM, HP, and even Sun do many far more interesting things.

    One other big problem from MSR - on the occasional project that's actually good, they somehow manage to kill it, or at least never tech transfer it into products. I cry when I think of some of the awesome dev technologies MSR was working on a few years ago that never made it out.
  • by cyclopropene (777291) on Friday November 11, 2005 @04:03PM (#14010898)
    Interesting...Singularity is ostensibly supposed to be about stability, but the 44-page paper has no data on this. Kinda like saying, "Our new bulletproof vest is 40% lighter than our leading competitors, and twice as flexible. How well does it stop bullets, you ask? Sorry...we do not yet have results for that benchmark.".

    You didn't really read it, did you? From TFA(bstract).

    ...Singularity demonstrates the practicality of new technologies and architectural decisions, which should lead to the construction of more robust and dependable systems.

    The point of the paper is NOT to demonstrate a fully working uber-dependable system, but to validate the practicality of the architecture that is under development, and the new technologies being included. That's why they have the section on performance, with the preface (right above your quote, btw):

    If Singularity's goal is more dependable systems, why does this report include performance measurements? The answer is simple: these numbers demonstrate that [the] architecture that we proposed not only does not incur a performance penalty, but is often as fast as or faster than more conventional architecture[s]. In other words, it is a practical basis on which to build a system.

    That's the point of the paper. I understand, however, that you might have been in too much of a rush to get first post that you didn't understand the point of the paper...

  • by someone1234 (830754) on Friday November 11, 2005 @04:23PM (#14011080)
    Hmm, Murphy is a known M$ shill, they must be very desperate to get clicks if he resorts to this kind of admission. Or there is some very dark reason i couldn't even fathom.
  • by pthisis (27352) on Friday November 11, 2005 @04:45PM (#14011304) Homepage Journal
    Yawn, same old stuff - read the rest, Windows is better at thread switching. That makes up for the slow process creation. Windows programmers know that processs creation is slow, and thread creation is quick.

    As a result, you get tons of unstable Windows applications because to get any reasonable concurrency you have to throw out the years of hard work that OS designers put into having protected memory.

    Threads vs. processes isn't "two different ways of doing the same thing". Barring a massive implementation boondoggle, you make that choice based on whether you want memory protection or not. These numbers highlight a massive boondoggle, which takes the correct choice away from the application author in many cases.
  • by norton_I (64015) <> on Friday November 11, 2005 @04:46PM (#14011314)
    Why do you think that is pointless? While it is not the same style of "basic" research as some of their other work (which is, as the original poster said, top notch), it is certainly valuable, at least from the abstract you posted. They also do some cool stuff with compiler optimization, distributed/parallel computing, and all sorts of more respectable forms of research.

    I don't know your background, but I have never met anyone with a substantial CS background to say anything bad about MS research, including a number of OSS zealots (such as myself). I suspect that most people who make fun of them are simply not in a position to judge their work.
  • by Shotgun (30919) on Friday November 11, 2005 @06:11PM (#14011997)
    Insightful? How about "apologetic bull"?

    My job is in QA. Your statement says that my job is impossible. Here are a few ways you can test stability:

    1) See if the OS comes back online after a power cycle
    2) Insert and remove device drivers
    3) Send mangled data across the various data busses
    4) Run programs that try to allocate all the memory
    5) Run programs that try to hog all the CPU
    6) Run a program that fills the hardisk/erases the hardisk/refills the hardisk
    7) Do all the above all at the same time

    The OS is a control point, and should be able to handle all of this and more GRACEFULLY.

    (Gracefully being an undefined weasle word indicating that it should fail in a somewhat predictable manner that won't completely piss off the vast majority of administrators.)
  • Re:But how...? (Score:3, Insightful)

    by pthisis (27352) on Friday November 11, 2005 @08:06PM (#14012747) Homepage Journal
    Threads certainly have a place, I never said otherwise. The problem is that the Windows system forces you to accept shared memory to get concurrency, and those two are unrelated. The number of problems that want concurrency and memory protection is large, and eliminating that option is a MAJOR problem.

    Having done a fair amount of GUI programming myself, I find a multiprocess solution is often correct (e.g. in something like Photoshop image filters, where you want shared access to one memory segment but don't need to share huge numbers of different memory segments where you can't easily compartmentalize them). For some jobs, though, multiple threads is better. Use the right tool for the job.
  • by r00t (33219) on Friday November 11, 2005 @09:04PM (#14013038) Journal
    I know this is going to be hard to believe, but...

    UNIX creates a process with fork, which takes no arguments. UNIX runs a new executable with execve, which takes 3 arguments. So in just two system calls with 3 arguments, you launch an app.

    Windows has a CreateProcess() [] function with 10 arguments, many of which are pointers to structs. I call your attention to the absurd "LPSTARTUPINFO lpStartupInfo " argument, which supplies info about the windows style and current desktop.

  • by Arandir (19206) on Friday November 11, 2005 @09:27PM (#14013132) Homepage Journal
    That's because GNU really has no clue about compatibility. Take a look at any non-GNU libc, and you won't have that problem.

Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read.