No More Apple Mysteries, Part Twoby Johan De Gelas on September 1, 2005 12:05 AM EST
- Posted in
The Aftermath of the First ArticleWe received a flood of mails and posts from our readers requesting that we test the Apple machines with Linux too and questioned why we hadn't done that in the first article. We have to point out that the objective of the first article was to compare the platforms, and therefore, it is only natural to use Mac OS X on the Apple machine. Very few Apple machines run Linux, but in this article, we test this combination to shed more light on our findings.
Secondly, we spent most of our time trying out different MySQL setups to find out whether or not the poor MySQL numbers were a result of bad tuning. We tested and tried with, for example, the "skip-locking", "key_buffer" and "thread_cache" parameters, but none of them could help the Apple platform to perform significantly better. The out-of-the-box MySQL setup on Tiger is not very different from a typical SUSE Linux out-of-the-box installation, except that skip-locking is not enabled on the Apple platform. The reason seems to be that quite a few Xserves are used in clusters. Enabling "Skip-locking" gives a 1-3% performance boost to the Xserve and PowerMacs. We can say with 99% certainty that the MySQL configuration was not the cause of the poor MySQL performance.
The vast majority of the reactions of the Apple user community were very positive, despite our low server benchmark numbers. Many Apple users told us that they were glad that we had pointed out that Mac Os X still needs a bit of performance tunings. Anand reported the same thing as what many Apple users pointed out, which is that the responsiveness of the OS is not spectacular:
"The overall responsiveness of the system was decent, but go back to using a top-of-the-line PC in Windows for a few minutes, and you definitely feel a bit sluggish on the G5"We still receive suggestions because of the first article, and one question that was asked a lot was: "why not test with different compilers?" The reason was that gcc was the default compiler on both Mac OS X and Linux. Testing with compilers would widen the scope of this kind of article too much, and we wanted to use the same compiler on all CPUs. That being said, we retested with the gcc 4.0 compiler because the 3.3 version performed pretty poorly on the Power FX platform.
I would like to thank the readers for the valuable feedback. In this second part, we'll correct the inaccuracies in the first.
Scope and FocusAgain, we are focusing on workstation and server applications, especially the open source ones (MySQL, Apache) as Apple is touting heavily the importance of their move to an "open source foundation".
The 64 bit Apple Machines were running OS X Server 10.4.1 (Tiger) and Yellow Dog 4.0 Linux version 2.6.10-1.ydl.1g5-smp. The reason we chose Yellow dog is that Terrasoft, the company behind this Linux version, optimises only for the G5. So, Yellow dog is by far the most PowerPC optimized Linux distribution out there.
Our x86 machines are still running a 64 bit server version of a popular Open Source Operating Unix system: SUSE Linux SLES 9 Service Pack 1 (kernel 2.6.5).
Post Your CommentPlease log in or sign up to comment.
View All Comments
Lori - Friday, September 2, 2005 - linkhttp://en.wikipedia.org/wiki/Microkernel">http://en.wikipedia.org/wiki/Microkernel
MacOS X uses a modified microkernel (a monolithic / microkernel hybrid). The idea was to cut down IPC costs by putting servers that would be IPC heavy directly into the kernel. However, there has recently been a lot of work in the microkernel world to reduce this IPC cost and bring its speed near that of a monolithic kernel.
L4Ka::Pistachio is an example of this:
leviat - Thursday, September 1, 2005 - linkIf the problem is indeed in the thread creation portion of the OS, it would be interesting to see how a single threaded webserver fairs. I would love to see a benchmark test of Lighttpd (www.lighttpd.org) to see a comparison of how that runs on Darwin vs linux-ppc.
Another interesting test would be to see MySQL can be configured to precreate the handler threads. This might allow us to see how it handles the context-switching between the multiple threads and allow for it to compete.
Anyways, great article!
JohanAnandtech - Friday, September 2, 2005 - linkWhat exactly to do you mean by single threaded? Because Apache 1.3 works with processes, and is thus single-threaded per user.
MySQL can make use of a Thread cache, we played with it but it didn't give any substantial boost. I don't see how the software would be able to precreate all threads as it has close down and open connections. If you got some insight, please share :-).
Context switching is quite fast on the G5 OS X, give or take a few percentages compared to Linux x86 or G5 Linux, as we tested with lmbench.
Lori - Friday, September 2, 2005 - linkActually there are more than one way to handle multiple connections in a server application.
To give you some examples...
1. Multi process
2. Multi thread
3. Some hybrid of the two
You can see combinations of these types all provided by Apache 2's MPMs. (perchild, prefork, threadpool, worker, leader.. etc)
4. Asynchronus multiplexing.
Your program becomes its own schedular. You can do all your processing within a single thread. Also read up on non blocking i/o. I am actually surprised apache does not have a MPM to handle this type of connection multiplexing but I also read its harder to get OS support.
Letsee... links... umm... ahh...:
Avalon - Thursday, September 1, 2005 - linkSeems like once you remove the G5 from OSX, it's a very capable chip.
jamawass - Thursday, September 1, 2005 - linkGreat article, in response to the previous post Anand has posted tons of server articles on x86 systems so Apple is fair game here. Secondly Apple servers are based on OSX in the market, corporations want to know the real world performance not the desktop feel. Also Johan's speculation on Apple's move to Intel raises some troubling questions for Apple execs.
karlreading - Thursday, September 1, 2005 - linka lot of people commenting on how apple have mad a wrong dicision turning to intel.
possibly, but IMHO, and, if im not mistaken, didnt the opteron dominate all the tests.
so in my mind whilst its true for people to doubt apple for going intel, x86 on the whole is still a very viable option if you go the AMD route.
yes i know people will say AMD dont hae the capacity, but amd powered macs should be how x86 macs are done.
karlreading - Thursday, September 1, 2005 - linkalso worth noting is that they say the FP poerformance is as good as the fastest x86 chip. well scuse me, but isnt that a 2.7ghz g5 part there testing there? thats the fastest g5 currently avalible isnt it? well then why not test the opteron 254. thats the fastest x86 chip, running 2.8ghz, rather than the 850/250 2.4ghz part tested? that would put some lead against the g5 and also, 2.8ghz is a lot closer than 2.4ghz is to the 2.7ghz g5's core speed. if were trying to be fair.
if we was being really picky we would be stating duakl core opteron as the fastest x86, but i digress....
JohanAnandtech - Friday, September 2, 2005 - linkYou are right about the recentely introduced 2.8 GHz Opteron. Well, to be really accurate, at the time of the introduction of the 2.7 GHz G5, a 2.6 Ghz opteron was available.
Anyway, It was not my intention to be "accurate", it was more a general impression. Give or take a few percent, the G5 can compete FP wise :-).
Pannenkoek - Thursday, September 1, 2005 - linkIt's a matter of scalability, SMP support and not so much of how fast some system calls are executed as the reason for the bad performance I would think. Linux is the most used OS for superclusters these days, Mac OS remains a desktop OS. It's no wonder that it performs poorly as a serious server on a multiprocessor/core system. It would have been interesting to see how Windows would have faired (on the x86 of course), if we are testing OSes in this way.
However, MySQL benchmarks say little about desktop performance, Anandtech's audience consists of desktop users and the reason people love or hate Mac OS is its desktop. Nevertheless, almost a great article. It should have been if the autor could have resisted the temptation of too much speculation, instead of honest benchmark numbers.