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."
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.
Processes in Unix are lightweight objects, and the OS spawns them left and right. Processes in Windows are heavyweight objects, and the OS creates only a handfull of them. The lightweight objects in windows are threads, and you'll notice that Windows thread creation is faster than Unix thread creation. These are just different OS design philosophies.
While technically, reboots are not required for anything other than kernel patches, there are lots of situations where it's easier to reboot than to restart every application (which might as well be a reboot anyways). For example, glibc updates will require almost every application to be restarted, or you risk exposing vulnerabilities.
If you need web hosting, you could do worse than here
really... how exactly do you replace a running libc?
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.
We live, as we dream -- alone....
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.
If corporations are people, aren't stockholders guilty of slavery?
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
If corporations are people, aren't stockholders guilty of slavery?
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.
Don't let THEM immanentize the Eschaton!
I don't have something I can point you at right, however, the information is true. Linux used to have horrible overhead imposed by thread creation. As a result of both the NGTL and NPLT projects, the time needed to create a thread on Linux is tiny...tiny...tiny...some of the well known results from the projects were published... Here's a quote:
"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
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.
Actually results are mixed; and they even seem to indicate that Linux seems to excel at nothing but quick process startup (which is cool if you do lots of shell scripting, maybe compiling too)
9 45599
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
I'm still trying to figure out what people mean by 'social skills' here.
Some of the things that Win32 processes do that SFU and native processes don't:
- The Application Compatibility Database, a user mode service has to be contacted to see if the new program needs to have any compatibility shims added. Half of the compatibility that XP has comes from modifying programs as they start, or giving them special treatment. This stage alone causes so much overhead that Windows Server 2003 has a special group policy that lets you turn it off to make starting processes faster.
- The Software Restriction Policies database, a set of registry entries that have allow/deny rules for starting processes based on hash, filename or certificate. To make any actual comparisons, the entire binary has to be hashed and checked for certificates before the program even starts.
- Registering with the Win32 subsystem server (csrss). This involves several out-of-process function calls.
- Load the current locale, including NLS files.
- If enabled, contact the Themes service.
Except for talking to the Themes service, all those steps are done for every new Win32 process, even if it doesn't have a GUI.I didn't say your job was impossible, but your job is only testing a small subset of reliability. Reliability is also whether or not the OS stays up for a year at a time, or whether it has long term memory leaks. Reliability also has to do with weird race conditions that only show up after several programs interact for a significant amount of time, etc...
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.
If you need web hosting, you could do worse than here