This article from IBM seems to confirm Anandtech results:

http://www-106.ibm.com/developerworks/linux/library/l-ydlg5.html?ca=dgr-mw01LinxOnG5%22

Performance is going to suck...if you use a compiler that isn't what ships with the system and can't autovectorize, can't even generate AltiVec code, use a version of MySQL that does fork() at random times, unlike the version of MySQL that ships with OS X Server, etc.

And "objective performance rating" isn't all that useful if you don't understand how a particular OS/application combination work, especially if different platform do things slightly differently.

The fact that microkernel architectures are a performance sink has been known for years (google Linus vs. Tanenbaum if you don't believe me).

Both Linus and Tannenbaum were arguing past each other in that debate, and Linus still doesn't seem to understand microkernels.

Minix was a bad example of a microkernel from the point of view of performance because its servers were deliberately simple to make them easier to understand... it's an educational OS, the fact that it was actually useful was serendipity.

Mach is a bad example of a microkernel because it uses a heavyweight mechanism (the VM system) as the basis for IPC, which means it doesn't have the option of getting a performance boost from running cooperating servers in the same address space. That's why OS X uses the BSD kernel, a monolithic kernel, to provide so many of the services.

A well designed microkernel like QNX has very fast thread creation and message passing, and I've pointed this out to Linus on multiple occasions. His latest response was that QNX is not a commercial success as a consumer operating system so it's irrelevant... if microkernels were so effective QNX would have "made it".

QNX is a real-time OS in the process control industry, and the only people trying to make it a consumer OS were a bunch of Amiga fans who didn't actually pay Quantum for their work. So the fact that it didn't "make it" is merely a reflection of the fact that it never tried.

Apple has a server platform it's called Xserve to the nimrod writer of this article. And it seems that the Xserve platform has done quite well for itself at many big companies with no performance issues.

Umm, OS X _does_ use MACH, and not the BSD kernel.

It does, however, use it as a monolithic kernel by loading kexts into the kernel address space instead of launching servers. This is a bad design but it gives them some performance benefits. The problem is that MACH's IPC does more than they need it to for day-to-day operation (ie: it has network transparency and other rather heavy features). Still, it is fast compared to writing to a socket and has less kernel memory overhead.

A light-weight microkernel like L4, QNX, or vxWorks makes for a really fast system. MACH is decent and we get really fast thread creation so it is something.

That, however, is not the debate at hand.

It sounds as though the article is wrong if it says that "OS X sucks because it doesn't use kernel threads" since that doesn't even make sense. How can the kernel not use kernel threads?

If MySQL is using some odd user-space thread library then they should fix it to use the native threads. If this is a library that ships with the system then Apple should probably make it use kernel threads (although their might be reasons why they don't - maybe some apps want to control their own threads, for some reason).

Did any of you read the Ridiculous Fish article referenced by the first post? The bottom line is that OS X is slower because it flushes the hard drive buffers correctly. Linux is faster because it doesn't force the hard drive buffers to write to disk. MySQL is faster because a very important data integrity feature is not present on Linux.

They Claim; Mac OS X 250 req/s, Linux 3800 req/s using; ab -n 100000 -c 150 http://localhost/ (so they run the test tool on the cpu itself)

Turn's out that if you run ab on Mac OS X with -n 100000, execution stalls from time to time, and so the it reports a lower then expected req/s

So I run on a dual 2.7 with a clean install of Mac OS X Tiger; ab -n 1000 -c 150 http://localhost/ -> 5900 req/s ab -n 10000 -c 150 http://localhost/ -> 8500 req/s (this one stall's sometimes) ab -n 100000 -c 150 http://localhost/ -> 250 req/s (always stalls) The drop off is due to ab and not to the web server, in fact the web server is idle and if you use another machine on the network to test the web server still under test, it's still fast and responsive.

So knowing that ab on Mac OS X was the problem when run with -n 100000, I run it from a linux box; ab -n 100000 -c 150 http://ip_address_server/ -> 5800 req/s So instead of being 10 times slower, Mac OS X server is around 1.5 to 2 times faster on that test against the Linux box. (66 Threads running very fast an not showing any problems in speed ;-)

If you want to run the test on a client machine, turn on the webserver, go to the terminal and type; ab -n 1000 -c 150 http://localhost/ Make sure you have a valid index.html file, Mac OS X tries to answer in your language so before running test go to; /Library/WebServer/Documents/ and rename index.html.en to index.html (otherwise you would see low req/s ... Depending on HW you should see 500 req/s up to around 2000 req/s, remember de server is tuned for performance that's why you won't see the numbers I mentioned unless you have a tiger server.

The slowness of mysql can be better understood if you go to; http://ridiculousfish.com/blog/

I will do some java server benchmarking with 800 threads, but as far as I can see it runs as fast as a dual Xeon 3.2 GHz ...

So Client yes, Server most certain! Look at, at the bottom you can see that my results are in the same trend; http://www.apple.com/xserve/performance.html

Apocalypse: OS X uses Mach *AND* the BSD kernel.

Mach is NOT a complete kernel. It provides little more than memory management, scheduling, and interprocess communication. It requires servers to provide all other operating system function. In OS X, and in fact in ALL production Mach-based systems I'm aware of, a traditional BSD kernel running as a server UNDER Mach is what provides almost all other OS services. Drivers are divided between traditional UNIX style drivers in the BSD kernel, Mach-based loadable drivers, and in some cases drivers that are loaded separately but run as part of the traditional kernel.

This is the "single server" approach. It takes advantage of Mach's modularity while avoiding having to perform multiple context switches between separate servers for every system call. If Mach were a properly designed microkernel, it would be possible to run multiple servers in the same address space and perform message passing between them without the overhead of a MMU context switch. This would not be "bad design", it would simply be an implementation detail that could be changed simply by changing the way each specific service was launched.

Lites, Tru64 UNIX, and Mac OS X are all BSD-based single server designs. The only Mach-based system I know of that isn't a single-server design is GNU's ill-fated Hurd.

Avoiding MMU context switches, by the way, is why applications may use user-space threads as well as or instead of kernel threads. If the threads are being created to implement a design that is inherently concurrent, rather than to coordinate with asynchronous events, it can be a LOT more efficient to use user-space threads instead of kernel threads because it reduces thread switching time to the same order of magnitude as a subroutine call.

I very confusing and not understandable for Joe average. Problem is that Jo avarages looks at test like that and takes it at face value. Might be the reason why arstechnica has those long reviews;-)

I read this article almost two weeks ago, along with everyone else. Why is MacNN reporting this as "news" now?