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.
I would have rpefered Apple going with AMD opteron's or contracting one of their other beefy 64 bit chips. Why intel?
;)_
I like the g5 chips, and sure the intel ones are okay. But it just seems like AMD would have been a better match for Apple.
Oh well, I'll take what I can get.
And I can't wait to move over a bunch of older intel's to mac os X.
-=fshalor
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 read this article yesterday when it was posted. For a news summary site, ./ isn't very quick.
/. articles.
Also, what's with the barrage of Apple/Intel/iPod/DRM/HDDVD/*AA/Lawsuit articles? These were interesting for the first few months. Just post a story every day that says:
"Companies sued other companies over pantents they shouldn't have, the *AA's are illegally abusing power they don't have and Apple did something so fantastic I crapped my pants."
There, I covered the last 6 months of
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.
...Why intel?...
One word: laptops.
C//
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
Apple has priorities. Just like linux sucks on desktops and rocks on servers, Mac OS X sucks on servers and rocks on desktop
There's always an anti-MySQL snob making dismissing remarks with nothing to back it up. Sure, they could go and propose a better benchmark, but that would open themselves up to the very same attacks that they think makes them sound smarter.
"By the report the G5 processors are just as fast as the fastest x86."
Which is funny, because they took the fastest available G5s and pitted them against the second fastest available single-core Opterons.
I also don't buy the gcc as an equalizer assertion given in the test. They've already shown that gcc doesn't produce apples-to-apples results, and now they've shown that it doesn't produce improving (or even consistent) results in newer versions.
I'm willing to accept that they've produced some real-world tests, but the synthetic ones are a bit of a stretch. Yes, the processors have similar performance envelopes, but saying anything more than that is just creating a conclusion with too little real information.
Huh? What about all those ads saying a G5 was a "supercomputer"? And what about those Pentium snail ads? How could you possibly say that?
By the report the G5 processors are just as fast as the fastest x86.
But Steve Jobs said they were much much faster, before he caved in and switched architectures. You can't rewrite history! (Well, you can, if you use the Wikipedia, but that's another topic.)
Best Buy can have you arrested
you know, people uses programs in their computers.
People using servers are probably very interested in seeing how server-oriented programs perform in a given hardware
Those are called "real-life benchmarks". They're much better than lmbench and tiny C programs running whatever microbenchmark in a tight loop because they measure what you actually are going going to do with your system.
It doesn't matter if your lmbench numbers are great, if the apps you're going to run don't run well what's the point? I can't see why mysql is a bad choice for a benchmark...
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...
When a prior test shows such extreme poor performance, at times a good review company will take the time to look into WHY That performance gap exists to make sure its not the fault of there tests and is indeed a issue with the hardware.
They are not beating a dead horse, They saw a problem with either the platform or there testing methodoligy and did all they could to find the issue
Personal Website
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
I would have rpefered Apple going with AMD opteron's or contracting one of their other beefy 64 bit chips. Why intel?
Currently Steve Jobs is using Intel to beat IBM over the head. Officially PowerPC is out of the picture, but it hasn't been announced just when G5 will stop - will it go dual-core? How about low-voltage?
Similarly, when Apple is largely x86 at some time in the future, Steve will have AMD to keep Intel honest.
I expect we will see regular rumors of Apple switching to AMD, followed by nice price cuts on Intel/Apple kit. Maybe even the Dell trick of "accidentally" leaking product code and spare parts pages for AMD based product. Makes the claim that AMD is being seriously considered look very credible when going to the regular meetings with Intel to negotiate extremely good volume discounts (Dell can't afford to sell AMD products, it would cause Intel to inrease its prices that it charges Dell, and at this point Dell is addicted to rock-bottom Intel prices - it's practically their entire business model).
And to sum up every test ever done on any platfor using any hardware....
Some things run better on some machines than others.
The End.
Seriously this article and the last and tons of other comparisons always end up with the same conclusions that we have known since the beginnning of time.
Apple's G5's with OS X run some apps really well and some apps poorly. Just like Windows XP runs some apps really well and some apps poorly. With Linux on both hardware platforms some apps run better on the Intel chips and some apps run better on the IBM chips.
Ave Molech Setting
That's because MS SQL is essentially just Sybase for Windows.
It was originally thought that Mach's poor performance was the result of the message-passing paradigm on which it is based, which seems a reasonable enough conclusion. This in fact causes a performance hit, but it actually turns out that it is not responsible for the majority of the hit. Most of the degradation in Mach was due to other overhead, such as checks for memory access rights. This costly functionality was needed in order to meet the design goal of transparency across distributed systems without compromising security.
For a fork() to occur, a port access right must first be checked. Then there is mapping between user- and kernel-threads. Those are the significant Mach bottlenecks. Linux has a much faster model for threading and scheduling (that 2.6+ scheduler is great!).
(%i1) factor(777353);
(%o1) 777353
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.
Yes, one can easily question if moving from the G5 to Intel will be a performance win. But there are no portable machines with the G5 processor. The iBook and PowerBook lines make up enough of Apple's profits that they can't allow them to plateau. Regardless of what advances IBM has made to the G5, they still have not provided any offering that provides Apple something that can match an Intel Centrino for revising portable products. My guess is that Apple will phase out the G4 before they move on to eliminating any G5 offering.