Slashdot Mirror
Microsoft Reports OSS Unix Beats Windows XP
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."
Now that you're done being sarcastic, go look into some of the research that is being done at Microsoft Research. Like it or not, it is top of the line work. They're at the cutting edge, and they're well financed.
Cyric Zndovzny at your service.
Like it or not, it is top of the line work. They're at the cutting edge, and they're well financed.
Okay, but how many of their innovations (Christ Microsoft loves that word!) actually make it to the outside world?
I think your comparison to Bell Labs is good, however, in that much of what Bell Labs created required others to make into real products. AT&T/Ma Bell sat on every innovation until it nearly suffocated due to lack of capital investment.
"Rocky Rococo, at your cervix!"
This is pretty typical. Microsoft's biggest competitor is their old software, so their new offerings have to look good against it.
Remember Windows 95's marketing? "32-bit memory protection makes it uncrashable!" Remember Windows 98's marketing? "Even more stable than 95!" Remember Windows 2000's marketing? "Based on an NT core, it's more stable than the crash-prone Windows 9x!"
Its revisionist history. The only way to get a somewhat accurate picture is if you compare their current claims with what they've said about new technology in the past.
Bogtha Bogtha Bogtha
This is the real big threat to the open source community. Once Microsoft becomes honest whith themselves they might start making real progress on the engineering side of their product. Marketing will get you so far when you have no more competition but good engineering can make it stick.
"A good friend will bail you out of jail. A true friend will be sitting next to you saying, 'damn....that was fun!'"
This is Microsoft Research. They have the same independence as university researchers--that is how Microsoft lures them away from academia. These guys are making honest comparisons to Linux and FreeBSD, because that is what they do as good researchers. Microsoft is enlightened enough not to interfere.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
You clearly don't know much about what makes an operating system stable... Stability depends partly on how much error checking the compiler is capable of doing, partly on how people write software (design) and partly on how well the operating system is designed to separate processes and different parts from each other. Singulary addresses all of these issues: Its mainly writen in a "safe" language which is strongly typed and does lots of compiletime check and it is a microkernel operating system which (at least in theory) prevents your cheezy usb webcam driver from crashing the kernel. Most other unix wannabe systems are writen in the ancient language C :), and run monolithic kernels.
:) (btw, I am a long term happy gnu/linux user, and have no plan of switching...)
But singularity isn't all new, it just implements old ideas: Occam and QNX!
But in my opinion, Singularity just might be the most interessting os to emerge in the last years. It will be interesting to see how long it will take the free software world to come up with something similar
Instead of paying rapt attention to what Microsoft is doing what I would like to see the OSS community do is consciously form more organizations that would as an express purpose chip away at Microsoft's software base. What I mean by this is make sure your program runs on Windows for now. Get people using OSS and used to the idea so that the next time average-joe needs some software he'll search for an OSS program first. Then once that mindshare has been established begin to work towards the more core functions like the OS itself. Who knows, Microsoft might at some point simply open up the source of Windows to counter a loss of control to OSS if they see that their customers are truly ready to abandon ship. And to build that feeling in customers give them options - if all their useful software is OSS then they can swap out the lower levels (like Linux for Windows) without feeling any transition pain at all because their software applications didn't change at all only the plumbing did.
Ballmer's right, it is all about developers. OSS developers can introduce OSS values into the Windows "ecosystem" for lack of a better word and see what happens.
Shh.
I don't know what those 5m vs 1m cycles are doing. But what I do know that fundamentally Windows was designed with high-performance threading/wait operations and high-performance asynchronous operations, whereas Unix and its derivates rely on high performance process-creation, blocking I/O for sever applications.
I.e. Apache 1.3x series performs poorly on windows because it was a straight copy of the Unix edition - using processes rather than threads.
It's a Microsoft OS, and you're saying that they made a mistake when mentioning that one of their goals is increased dependence? Hell yes that's their goal. Vendor lock-in, forced upgrade cycles, dependence - all the same thing, and all the goal of any winning software company. :)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
A great product is a great product regardless of who makes it. I thought OSS was a big deal because it emphasised great engineering with openness. So, if you can't handle the heat, then stay out of the kitchen.
The fact that the virtual machine is a bit slower isn't the point. The point is that because the virtual machine ensures memory protection, Singularity doesn't need to use hardware memory protection for the kernel. Doing a single system call costs hundreds of clock cycles on a modern CPU, because of the userspace/kernelspace switch. It also necessitates all sorts of complex (and slow) IPC mechanisms that go through the kernel (and invoke the aforementioned switch), all because we're still programming in an antiquated 1970's era language that let's programs randomly write into memory.
Modern CPUs quite be quite a bit faster if they didn't have to support C. Take a look sometime at all the die space an Athlon64 uses for stuff like TLB, etc. Also look how it needs to increase L1 cache latency by 50% (from 2 cycles to 3), just to support the TLB lookup. All of this stuff would be unnecessary if C programs couldn't overwrite whatever memory they wanted.
A deep unwavering belief is a sure sign you're missing something...
Throw out years of hard work? Give me a break! It almost seems that you are blaming the poor quality of modern threaded applications on Windows! That's rich!
Concurrency is difficult to use correctly no matter what technology you use. Inter-process shared/mapped memory is just as susceptible to race conditions as cross-thread shared memory, and inter-process synchronization logic can deadlock just as easily as thread synchronization logic. And the results are the same: once a process is deadlocked, or corrupts its data due to a race condition, what difference does it make if it's running in its own address space? The software has failed catastrophically either way!
We are ALL well aware that poorly written multi-threaded software is unreliable and that threads can easily trash other threads' data if not written correctly. And yet, for performance-critical applications, programmers still prefer to use threads. Why? It's simple: Because, for MANY applications, the benefits in performance outweigh the risks.
Finally, I'd like to point out one more thing. You claim that to get "reasonable concurrency" on Windows you are FORCED to use threads. I completely disagree. While process startup latency is relatively high on Windows, Windows offers a rich set of interprocess communication mechanisms, and context switching is quite fast. And if your program is so performance-critical that process startup latency is your biggest bottleneck, then switching to thread synchronization seems perfectly reasonable.
Shame to have to set up like this just to run unreal editor, though. Oh, for you gamers out there, UT runs so much smoother and faster in Ubuntu, it's not funny. UT2k4 (has linux installer on the 1st cd) runs way better in Ubuntu also. You might want to check it out if you have a spare hard drive you can play around with.
Karma: Bad is the liberal way of saying this guy won't drink the kool aid here on slash dot. I wear my Karma with pride
You're misreading. It's not 90% of the problems out there, it's 90% of the code in a given program that's synchronous.
I really doubt that.
Take, for example, the process of reading data from a single input source and processing it. With no other input sources to look at, and no processing that doesn't require the data you're trying to read, exactly what can the code do while the read's completing?
That's not a typical modern server or end user application.
You incur the overhead of creating a thread, and then the parent simply blocks until the child thread completes. Less overhead to simply do the read in the same thread as a simple function call
Who was suggesting that we should call functions in a seperate thread when the operation is synchronous? My example was an example of how silly it was for you to state that a shared address space between async operations weren't needed.
You incur the overhead of creating a thread, and then the parent simply blocks until the child thread completes.
I would think someone with your experience would know about something as basic as thread-pooling.
Most of a program is like that: the caller can't proceed until the function it's called returns it's results, so running the called function in a seperate thread doesn't actually result in any parallelization
That most programs today aren't GUI applications where the UI should not be *blocked* whilst some request is processed? Even something as basic as IO can easily be made asynchronous as there is almost always some post processing to be done after a file or part of a file is loaded into memory that can be done whilst the next block is read.
Most of a program is like that: the caller can't proceed until the function it's called returns it's results, so running the called function in a seperate thread doesn't actually result in any parallelization
Sounds like you need to be more creative in how you design your applications. Most modern applications aren't top-down flow chart style processes.