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.
Why, oh why, do they insist on MySQL? They state in the article that they learned of the FSync bug in MySQL (which many of us pointed to last time). Why don't they throw PostgreSQL in there and see how it performs?
Javascript + Nintendo DSi = DSiCade
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...
No worries... Apple will come out with iSQL and things will be all better.
Sam
The problem is that this correction is still wrong. OS X has never been based on FreeBSD's kernel.
:-/
Better, but still imprecise. The Mach kernel isn't actually a full kernel. It's a super-kernel on top of a traditional Unix kernel. For testing, the Mach research project used the BSD 4.3 and 4.4 kernels as the basis for the Mach code. By the time of Rhapsody (later OS X), however, BSD 4.x was an extremely old codebase and was in dire need of updating. So Apple did what any smart programmer would do. They grabbed the most recent evolution of the kernel source (FreeBSD) and used that as the core.
That being said, the FreeBSD part doesn't do a whole hell of a lot. Apple has mostly replaced the traditional Unix bits with NextStep Frameworks. The advantage to these frameworks is that they're much more object oriented and easier to work with than their rather primitive ancestors. The downside is that these frameworks are written in ObjectiveC, which means fun times for driver writers.
Javascript + Nintendo DSi = DSiCade
It has nothing to do with FS performance and everything to do with the fact that Apple's implementation of threading has considerably higher overhead than Linux.
OS X has never been based on FreeBSD's kernel. ... OS X's kernel has always been based on OPENSTEP's--a Mach microkernel with custom Unix services above it.
And where do you think those UNIX services come from?
Because the answer is, FreeBSD.
Mach isn't a kernel by itself, it provides very low level services and "hosts" the rest of the kernel (though Darwin blurs this line somewhat, such that the mach microkernel and hosted freebsd kernel are technically the same entity). FreeBSD isn't the entire kernel (and its portion of the kernel isn't the part that provides threading services, see link above) but it is still in the kernel and still provides crucial functionality, and serves as a replacement for certain things which in the pre-OS X kernel used to be provided by OpenStep code.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Apple didn't choose AMD for a couple big reason. One of them was given by Steve Jobs when he announced the transition - Intel's roadmap offers better performance per watt of power than AMD or IBM can. Because laptops are taking a greater marketshare than desktops, it only makes sense for Apple to have a portable chip that produces the most bang for the least amount of power.
The other issue is fab capacity. AMD doesn't have the capacity that Intel does. Apple got burned more than once by a lack of chips coming from Freescale/IBMs fabs. They do not want to go through that again, and AMD has trouble delivering large volumes of their top-of-the-line processors. They've gotten better, but Apple doesn't want to be held back by a lack of fab capacity.
I use AMD for Windows and Linux, but Apple's business plan makes Intel the best fit for their future directions.
But there's so much more here at slashdot! Let's add "Companies are also suing other companies over patents/trademarks/copyrights they don't actually have." That covers SCO and the recent LMI stories.
We also have the occasional:
"Somone built a PC out of weird parts,"
"Big brother gained new, over-reaching powers that will bring society to its knees,"
"Some OSS figurehead (Stallman, Raymond, etc) said something idealistic/naive/irrelevant/stupid/arrogant,"
"Researchers at a small University made some irrelevant, impractical advance in so-called nanotech that will never affect anyone but makes us crap our pants,"
"Europe is far more enlightened than the US because...,"
"Some government switched from Windows to Linux,"
"Some government used Linux as a ploy to get cheaper Windows pricing,"
"Someone at Google farted,"
"Roland Piquepaille got a story on his 'blog' accepted by ripping off the AP feed,"
"Fudged TCO studies show that OS 'A' is cheaper than OS 'B,' and far cheaper than OS 'X'..."
"Microsoft is still evil,"
"An exploit is discovered in Windows that allows...,"
"Will we be able to do in 100 years some ridiculous thing that I've read about in tons of sci-fi novels but is completely pointless in real life?"
... etc. Yes, this is our slashdot.
Given that the Mac community are more concerned over Photoshop than databases its not really suprising that they haven't concentrated massively on transactionally written files (lots of small writes) and may have chosen to focus on optimizing the writing of big files and the maths and graphics processing that goes with graphics work.
More and more I consider the "Mac users are primarily photoshop users" to be somewhat of a strawman. I work at a Java shop, and many of our programmers, myself included, use Macs. So does our change management guy and much of netops. Yes, the graphics designers use Macs, but Macs are used throughout the company by many people for different reasons.
Blah blah blah, benchmarks are nice, but here's the real scoop:
I have a dual 2ghz PowerMac G5, a 3.4ghz Dell Opitplex and a 3.6ghz Developer Transition Kit. I use my G5 as my main computer at home and my Dell and DTK as my main machine at work.
The DTK smokes my dual 2ghz badly, and runs PPC apps in Rosetta at seemingly only slightly slower speeds than my G5. Graphics functions on the DTK smoke my dual G5 with the high-end (at the time) NVidia card it came with. Apps load much faster, Safari is much faster, everything I use is much faster.
The DTK's UI responsiveness is quicker than my Dell 3.4ghz running Win2003 with all hardware accel turned on. OS X has always been more sluggish for me than Windows, but I had to chuckle when I logged into my Dell after using the DTK for a week exclusively and noticing the Dell UI responsiveness slightly lagging.
It's also important to note that the NeXT ABI is probably much more suited to x86 than PPC.
This is a great thing for Apple, and their Intel-based machines are going to impress and wow people.
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...
Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs
Unlikely. Just because you can, doesn't mean there is any good reason to, and most desktop application developers will have absolutely no reason to bother with threads at all. The vast majority of desktop apps just sit idle most the time, and even the odd moment when they're busy it's mostly just to do basic things like redraw buttons etc. Thus threads will provide a grand total of zero benefit in almost all desktop applications --- yet they come at a cost to developers in that they increase software design complexity and make debugging harder. Most desktop application functionality is inherently synchronous too (driven by user interaction), so I think very few applications will benefit from being multi-threaded. Applications that might are e.g. word processors with background spellchecking and grammar checking, but really, these are still only going to launch a small handful of threads at most. Even CAD apps and applications like Photoshop that do occasionally require lots of CPU when activating certain functions will draw comparatively little benefit from increased design complexity in making a few processor intensive functions utilise multiple threads.
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.