Microsoft Reports OSS Unix Beats Windows XP 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."
No it doesn't. (Score:1, Informative)
Article misses the point (Score:4, Informative)
This article takes a very interesting report on a reference implementation of some innovative ideas in OS design and reduces it to a couple of entirely peripheral, seat-of-the-pants benchmarks that support the "OSS rulez!" thesis.
Even people like me, who have only a basic knowledge of OS architecture, can tell you that processes are lightweight in Unix and heavyweight in Windows. The lightweight objects in Windows are threads, which is why Windows makes so much use of threads, while Unix spawns processes left and right.
Re:Give me a fucking break (Score:3, Informative)
(I'm not being sarcastic: I haven't yet had time to read the full report, and would genuinely like to know.)
Re:What's the point of CreateProcess benchmarks? (Score:3, Informative)
Re:44 pages and the main question is still unanswe (Score:5, Informative)
Comment removed (Score:2, Informative)
Re:44 pages and the main question is still unanswe (Score:3, Informative)
init 3
No reboot required
Re:44 pages and the main question is still unanswe (Score:1, Informative)
The entire paper detailed the steps they were taking to make dependability the core goal of Singularity. That there are few reasonable metrics more measuring something as subjective as 'dependability', is not a criticism of this paper.
Grandparent is an idiot, most likely. Submitter of the entire article is dishonest in his quoting of metrics out of context and ignoring the point of the paper.
I read probably 60% of the paper. In short, they're using better languages to write a familiar operating system with some formalisms in place of add-on hacks of old (like shm, sem, threads)
Re:44 pages and the main question is still unanswe (Score:4, Informative)
Typical distros that support pervasive no-reboot updating (like Debian) don't exactly replace a "running" libc (or any other library), they simply update the on-disk copy. So any programs run after that will get the new libc, but any programs that were started before the update will of course be using the old libc.
Usually this works very well; I suppose for a mega serious security update you might want to restart all your daemons too or something.
Re:OS in C# ??? (Score:1, Informative)
2) The virtual machine is not the same as the
Re:Where is your fantastic research? (Score:3, Informative)
Re:Linux is NOT a Unix Variant (Score:3, Informative)
Re:44 pages and the main question is still unanswe (Score:5, Informative)
For example, apache and sshd, and various FTPds, can be restarted without anyone possibly noticing, because they simply leave any running children open. You connected before a certain time, you got the old copy, you connected after it, you got the new one.
And, of course, many protocols work fine if you go away for five seconds, like SMB. The client program will just say 'oops, connection hiccup' and reconnect silently, and the end user never notices. Same with IMAP clients. They go 'Hey, the server closed my connection, I better open it again'.
Restarting services on a Linux box is 99% transparent to end users, even ones that are currently directly doing something with the server.
Rebooting is not transparent, even if all the connections are reaqquired automatically, simply because work stopped for the two minute reboot.
Re:44 pages and the main question is still unanswe (Score:1, Informative)
I was making a funny, as in ha-ha. You guys are worse than Fark mods.
Re:Too Telling (Score:4, Informative)
It just doesn't beat it by as the absurd amount as its process creation beats MS's process creation.
Think of it this way:
Linux threads: great
Linux processes: great
Windows threads: good
Windows processes: horrible
Re:44 pages and the main question is still unanswe (Score:5, Informative)
mmm... I can see that in a few specific cases, like if you have a lot of users who log on over ssh. Less so for webservers and remote filesystems where you bounce the runlevels fast enough, the interruption will probably never be noticed.
Of course, the context where the Curse Of A Thousand Reboots really bites is for the home computer. I mean, I only have one user on this machine. Rarely I'll have two, never any more than that. So if I cycle runlevels, no-one is going to be put out bar me - and I'm the one doing it.
In General, I find that the people inconvienced by a compulsory reboot are not networked users.
Of course, even if you have remote users, your downtime is going to be a lot less if you don't have to go through POST, bios initialisation, device scanning and all the rest of it. And of course you only have to do it once, becaue you're controlling the process, so you don't get fifteen reboots in a row because windows brute forces everything.
So, I think "all but name" is overstating the case. By rather a lot, actually.
Re:Too Telling (Score:5, Informative)
"One test mentioned in Ulrich's email - running 100,000 concurrent threads on an IA-32 - generated some interesting discussion. Ingo Molnar explained that with the current stock 2.5 kernel such a test requires roughly 1GB RAM, and the act of starting and stopping all 100,000 threads in parallel takes only 2 seconds. In comparison, with the 2.5.31 kernel (prior to Ingo's recent threading work), such a test would have taken around 15 minutes."
http://kerneltrap.org/node/422 [kerneltrap.org]
As you can see, the stellar increase in thread performance has been unbelievable. Keep in mind, prior to this effort, Linux's thread creation was no where near the performance delta gained from these projects. Ergo, one can easily deduce that Linux far exceeds (less time) Win's thread creation latencies.
This is not true (Score:5, Informative)
According to the benchmarks published there
- at most OS jobs like threading/process creation, Singularity is at least twice as fast as linux, Linux is very fast at process creation, while XP is good at threads
- in File Operations FreeBSD and Linux beat XP and Singularity at random reads
- in File Operations XP beats Linux and Singularity at sequential reads, with the exception of FreeBSD being fastest if blocksize is high(and very bad for small blocksize)
- linux executable sizes are larger than these of the other OSes, (whatever that means, more good coding, or less bad code SCNR)
Please bear in mind that a benchmark does not tell whether the "slower" OS actually invested more time in doing some smart stuff that pays off in some other way. In particular, I would not be surprised if an experimental OS like Singularity did less.
partial repost from http://slashdot.org/comments.pl?sid=167223&cid=13
Re:5,376,000 cycles for Windows/XP (Score:3, Informative)
Win32 vs Posix processes (Score:5, Informative)
Some of the things that Win32 processes do that SFU and native processes don't:
Re:Typical slashdot post exaggerations (Score:2, Informative)
The executable thing is a figment of comparing apples and oranges, the Unix code was statically linked, which is basically including all sorts of stuff that you wouldn't in the real world.
Good dynamic linking is something the Unix (and clones) have done for a while (read long before Windows even started on this route), and was why we could run fully featured, X Windows based, Office suites (and Window managers) for umpteen users simultaneously on 125MHz PA-RISC machines with 100 or so MB of memory, and still have memory spare. And you still see this edge if you compare terminal services like deployments.
The cost of operations is less on pretty much everything but thread stuff, but then the cost of creating a process is so low in Linux, threads are more of a convenience for programmers than a structural component, as others have discussed. Although I think there are advantages to good thread handling, cost of creation can usually be mitigated by maintaining pools of threads (as can the cost of process creation in Windows for certain tasks), certainly the typical environments where one uses threads for performance reasons (think Apache2).
The tests basically tell those who understand computers, that they understand them correctly. Windows is faster at creating threads, the Unix crowd is better at pretty much everything else. It is what you'd expect comparing server class OSes against a desktop system. No one really cares if XP can't fork a process efficiently, if you only run a new application every half an hour, but if you fork (or prefork) for every incoming email request, you better do it efficiently.
I don't quite follow the sequential I/O for small block sizes, the default blocksize in the Unix world for the traditional filesystems is typically 8Kb, and no one ever opts for smaller (well some of the new filesystems do), particularly if they expect a lot of sequential I/O when they opt for bigger, so faster sequential I/O for block sizes less than this is I suspect of no relevance in the real world. Probably just indicates code in the Unix systems that assumes a larger block size, and is thus redundant. Kind of like discovering that a human brick layer out performs your wall building machine, if you break all the brick in to pieces before you start, interesting, but mostly shows your wall building machine expected bricks to be, well, brick sized.
Re:44 pages and the main question is still unanswe (Score:2, Informative)
The reason you can replace something like libc on a running Unix system, is the result of the way the Unix FS works. If you open a file, in this case libc, the kernel sets a reference count on that inode. If you subsequently unlink() (delete) that file, the kernel doesn't actually remove it until the reference count goes to 0. This means already running processes will be unaffected by this change, while new opens would fail.
In the case of a libc upgrade, one unlinks the old file, and replaces it with the new one. New apps start and link against the new libcxx.so. Old apps work as expected.
Windows doesn't work this way, at least not what i've seen
--
Mu
Re:What's the point of CreateProcess benchmarks? (Score:3, Informative)
There are 2 seperate issues here
1. Are threads faster than process? Yes, on both Unix and Windows.
2. Are process so slow as to be essentially unusable for concurrency? On Windows, yes for a relatively large problem domain.
(2) is wrong. You force the programmer to give up memory protection in order to use an unrelated feature (concurrency).
There are times when a threaded architecture is appropriate, and that is harder to do in Unix (which is why Apache 1.x spawns processes, even though the 2.x codebase shows that threads are a better idea).
No, Apache used processes because they were a better idea. That's why most sites running 2.x on Unix continue to run it in multi-process mode even though multithreaded mode is available.
Not only does the multiprocess model avoid synchronization issues (see, e.g., http://www.zeuscat.com/andrew/work/aprbench/ [zeuscat.com] for benchmarks showing that pre-fork is faster) but it avoids all the security/stability issues that come along with multithreading.
Would you rather have an obscure bug in some module you're using kill the current connection (and if it's repeatable, make that one page unloadable) or take down the whole web server? Do you want to limit the scope of security breaches?
Now, thread switches on their own are faster than process switches. With careful crafting you could design a threaded server that avoids synchronization issues and have it be faster than the multiproc version by that margin--but that's a very tiny margin that will likely be lost in the noise in any real-world server, and you're talking about increasing development cost dramatically for a return that's marginal at best. You'd be far better served putting that development effort into a state-machine based solution like thttpd or phhttpd if that level of performance is a concern.
That said, threads do have their place. Some problems are best solved with a shared-memory solution where the memory you need to share can't be easily isolated into a few SHM segments. And when that's the case, threads are the right tool for the job.
But the point is that if you don't have a reasonably performant process implementation then you remove the more commonly useful tool and force programmers to accept one feature (memory sharing) that could be very bad in order to use the one they really want (concurrency)--when those two features are really unrelated.
This problem isn't limited to Windows, either; Java similarly suffers from having no good way for programmers to use a multiprocess design.
It is, IMO, the single biggest technical problem with Windows.
Re:44 pages and the main question is still unanswe (Score:4, Informative)
What you're testing is simple stuff, stuff that's easy to identify. There's a whole other class of reliability testing that's far more long term.