Slashdot Mirror
No More Apple Mysteries Part Two
UltimaGuy writes "Anadtech has an article up comparing the IBM G5 with Intel's CPU. This gives us insight on the strength and weakness of Mac OS X. It also has some thoughts of what they perceive to be OS X's Achilles Heel." From the article: "That is what we'll be doing in this article: we will shed more light on the whole Apple versus x86 PC, IBM G5 versus Intel CPU discussion by showing you what the G5 is capable of when running Linux. This gives us insight on the strength and weakness of Mac OS X, as we compare Linux and Mac OS X on the same machine. The article won't answer all the questions that the first one had unintentionally created. As we told you in the previous article, Apple pointed out that Oracle and Sybase should fare better than MySQL on the Xserve platform. We will postpone the more in-depth database testing (including Oracle) to a later point in time, when we can test the new Apple Intel platform." This is the sequel to another article, reported on in June.
The first thing jumps to mind is a typical fanboy response: "The Mac is a desktop computer. If it runs MySQL good enough for a prototyping environment, that's fine. Where else can you get a great desktop environment that just works, along with a built-in Unix-like OS?"
But I should step back from that statement. It shouldn't be that way. We should have a truly world-class server combined with our desktop experience. I should be able to go from prototyping my web apps right to production, without a bunch of migration or guesstimation.
I really like Mac OS X, but I'm not above recognizing if it's flawed in certain aspects. Any word on whether Mac OS X Server performs these types of operations better than the client? That would be interesting - somewhat troubling, but interesting (and perhaps not even that troubling.)
concrete5: a cms made for marketing, but strong enough for geeks.
This guy said he'd run each OS through workstation-like tests, but all I see is a bunch of server tests and a lame "isolate the FPU" test.
And calling OS X's threading its "Achilles heel" is a bit short-sighted and belies an ignorance of OS design choices. Mac OS X adds an extra layer of communication for threading, so you can have user-space threads. This of course, comes with a performance penalty. In Linux, everything is a kernel thread. This gives it a big performance advantage, making it appropriate for servers operating under controlled conditions, as the tests indicate. However, OS X's design choice makes for more secure communication between user-space threads and the kernel, which gives an advantage in the workstation-space, since you can keep a user process from running amok in the kernel.
I've always said that Linux is a great server OS, and these tests certainly show that. But they're very tilted toward Linux's strengths and OS X's weaknesses, so OS X comes out looking like a ball-and-chain on Apple hardware. The author made a fundamental mistake in assuming that server stress tests were the be-all and end-all of performance computing, and that's just not true. OS X's designers made different design choices than the Linux designers did. These aren't choices that can be "fixed".
All he's shown here is that OS X is not appropriate for a high-demand, single-application server, and that's not really news to anyone. At the desktop level, no one's going to be working with thousands of simultaneous threads.
I tried for three days to get bluetooth to work on my pc laptop, and never did. I did it with a powerbook in 3 minutes. That's the performance I'm concerned about, not a few seconds here or there.
I think it tells you something about the mentality at AnandTech that the only criteria they have for choosing a computer are: 1) performance in a benchmark that has nothing to do with any normal user's needs and 2) the shininess of the case.
I think I speak for most Mac users when I say that I couldn't possibly care less how many MySQL transactions my computer could (but doesn't) run per second. There is undoubtedly a more cost-effective way of building a dedicated MySQL server, and they should be used -- as long as I get to keep a Mac on my desk to connect to it.
What I'm listening to now on Pandora...
The problem is that this correction is still wrong. OS X has never been based on FreeBSD's kernel. Although it has strived to ensure its BSD API matches FreeBSD, and has even ported over some custom extensions (such as kqueue), OS X's kernel has always been based on OPENSTEP's--a Mach microkernel with custom Unix services above it. OS X has had native threads since OS X 10.0 through the NSThread and Carbon Multiprocessing APIs. I don't know whether POSIX threads followed a different route, but the statement that OS X only got native threads in Tiger is simply wrong.
After reading the thing, here you go: OSX Server is significantly slower than Yellow Dog Linux (Server)running the Big Three on a G5. How many people try to run enormous traffic sites on OSX Server? Nobody?
It seemed that the authors were trying to make a point about the G5 vs. X86, and why Apple switched, but unless I missed it, there isn't any discussion of OSX Server on X86, or the opportunities that brings. It only seems to discuss OSXS vs. YDL on G5's. OK, Linux is faster. So? I don't get it.
Friends help you move. Real friends help you move bodies.
Never forget: 2 + 2 = 5 for extremely large values of 2.
And none of that changes that fact that MySQL has problems on the Mac. If you know it has problems, then why continue beating a dead horse? If you want to test MySQL again, fine. But get another application for testing in there that isn't screwed up!
Javascript + Nintendo DSi = DSiCade
how hard would it be to write an extremely simple program that calls pthread() in a loop, counts the threads, and issues a timestamp?
If you think the bottleneck is in thread creation, test thread creation, not fork(). They're not the same, and OS X does enough odd stuff with processes that I'd not be shocked in fork() had a bunch of extra process-related overhead that pthread() does not.
I'm not saying that thread creation isn't slow on OS X- it likely is... but please, if we suspect that's the problem, *that* is what we want to see tested! This article and AnandTech's testing methodology somehow explicitly misses the point of what they think the problem is... and it doesn't seem like it should be difficult *at all* to write a simple test to address *exactly* that problem.
Write a simple pthread() benchmark. The code could probably fit on one screen. Publish the code, run the test, file a bug with Apple, be done with it. A simple pthread() benchmark will tell us if the problem is in pthread() or fork() at this point, wouldn't that be nice to know *for sure*, so we don't have to speculate?
All this mucking about with MySQL doesn't tell us where the problem is, and I don't understand what's so difficult about coming up with a simple, pure pthread() benchmark... again, I *do* agree with the author and think OS X pthread() is the problem, I'd just like to see a simple, pure test that *shows* that it's *the* problem, so I can file a bug with Apple...
No, they *think* the problem is threads. As another poster pointed out they're still plenty clueless about what's actually going on.
Arguments about when OS X got native threading (which is what your link there is about) are moot. What is at issue is the performance of the OS X threading architecture. From the article (by way of Apple):
"POSIX thread (commonly referred to as a "pthread") is a lightweight wrapper around a Mach thread that enables it to be used by user-level processes. POSIX threads are the basis for all of the application-level threads."
So the use of lmbench to get an idea of how fast OS X handles thread and process creation is valid. Therefore, your link does not invalidate the lmbench results of Johan's tests, which were done as part of a search to find out why MySQL performed so much worse in OS X than in Linux on the same hardware. People can whine and say MySQL is broken, but you can't argue with the lmbench results. Process and thread creation in OS X is simply slow.
"Anyone that has ever gotten an idea based on any of my work and done something better with it-good for you."--J.Carmack
What a stunningly dumb article. Great high-level point of view on what problems can bubble up and look like, but no low-level understanding of what the problems *are* at all.
For example:
- Under 10.4, you need to ensure sockets get TCP_NODELAY, and that you don't try and use corking via TCP_NOPUSH or TCP_CORK. Memcached users are watching stuff *crawl* when they hit it, depending on the buffer size you happen to be using.
- Whinging about thread creation overhead ignores the fact that just about everything that uses heavily threaded environments use a thread pool and/or worker system - so thread creation overhead is pretty much a red herring in most app design. Sure, it's not brilliant that it's there, but it's also pretty pointless to talk about.
- As anyone who used poll() under heavy load knows, Panther could core dump; Tiger has improved, but it's poll() implementation is still suffering.
- There is, actually, a hidden cost on Macs - POWER state load/store is a lot more expensive, and the context switches are much higher. Tasks which cross the kernel barrier heavily do indeed pay a higher cost on the mac. This requires that folks who are used to 'cheaper' system calls think a bit more about how they can efficiently move their data in the smallest number of syscalls.
- And let's not forget to mention the exponentially more expensive cost of misaligned data access on PPC, easily invoked accidentally in code.
I mean, even once you get past the worse-than-one-might-want performance of the poll() causing problems, you've got the critical problem with TCP latency stepping in.
Strangely enough, all the tests they did that actually show problems are either known bugs, with known workarounds, or are known differences in behavior...
At some point, someone needs to call a spade a spade - was Apache built using TCP_CORK? You betcha. Was he using a fixed version of MySQL? Nope. Did the form of the tests for MySQL also succumb to the TCP_CORK problem? Almost guaranteed.
A poor test. Next time, pay some monkey to *write some code* if you're trying to prove the 'cost of latency'; if you're trying to prove that most Unix software isn't brilliantly optimized to work around issues which have existed on the mac for some time? Well, everything takes time, doesn't it.
-- A mind is a terrible thing.