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."
It explains why apache for windows uses threads. Everyone has always known creating processes is slow on windows. Unix has always heavily optimized this since unix programs were so frequently written to fork(). Very few windows programs spawn processes at any rate that would cause you to notice a slowdown.
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.
Are you saying that Paul Murphy's statement that, "almost every result [in the published report] shows Windows losing to the two Unix variants." is inaccurate?
(I'm not being sarcastic: I haven't yet had time to read the full report, and would genuinely like to know.)
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
Because a gigahertz is a BILLION hertz, not a MILLION.
With spending like this, exactly what are "conservatives" conserving?
init 1
init 3
No reboot required
--fatboy
He did not read the paper at all, as far as I can tell.
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)
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....
1) Written in Sing# not C# .NET virtual machine. They've implemented a much tighter and leaner "VM" and interwoven it with the kernel. In addition, some of the "stuff" in the .NET VM and base class libraries are handled by the Sing# compiler differently than the C# compiler.
2) The virtual machine is not the same as the
Here
"reality has a well-known liberal bias" - Steven Colbert
It's funny that you should mention that Linux is not Unix, as I'd dare say that Linux = Linux is not Unix, or LinUx. :P
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?
Troll? Bullshit.
I was making a funny, as in ha-ha. You guys are worse than Fark mods.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
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.
My always on XP SP2 machine has not had any spyware in 3 months. Its the dumb users who get infected. There are less dumb people using Linux (due to the learning curve), therefore less problems with unwanted computer activity. An XP machine properly set up with firewall, spyware, and virus scanners/blockers, and used responsibly (no Kazaa) will get a serious virus about as often as a *nix user will get rooted.
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.> 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)
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.
Perhaps everyone knows this, but...
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
I didn't mean to say that there aren't some negative consequences to the choice of making threads performant and processes less so. There are, and your post correctly identifies one of them. But I think it's wrong to say that that design decision is therefore across-the-board wrong.
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/ 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.
rage, rage against the dying of the light
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