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
Apple has always been about features at the cost of some speed.
I wouldn't be too surprised if "Leopard" could run win and linux apps each in their own window, thus the need to keep the app threads separate from the kernel threads.
By the report the G5 processors are just as fast as the fastest x86.
Comments?
"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?"
I agree, but you have to look at Apple's stance with the Xserve. The earlier article that is listed in the post was devastating, almost to the point of 'who would want to deploy an Xserve as a server?' type of deal. If they deal with that and make OS X Server really hope on the Intel/Mac Xserver, lookout, as then it'll be really something to consider. (/me crosses fingers)
bad_outlook
--
Is this vague enough for you?
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.
Sure its interesting to compare the Mac OSX with Linux on the same tin and see where one is faster than the other, and sure it might mean that Mac OSX Intel is going to be poor at running MySQL too....
But in terms of a fair evaluation and "no more mysteries", what they haven't covered is why transitions in the GUI are so much smoother than those achieved by Linux or Windows...
An Eye for an Eye will make the whole world blind - Gandhi
Linux is awesome, I'm not denying that, but its OS X server that matters, even if it may be slower, It's great to use as a school website server, and as a workstation at the same time. Not to mention that Server Admin, and a couple of the other applications for OS X server management make it a breeze to keep up to date, and running properly, as well as for initial configuration. Linux just couldn't do that for us. (read, not all super technical people dealing with the server next year).
Ok, MacOS X server performance is crap, not news. G5 is an ok to good CPU, not news either.
The question is, is it possible to get a non-apple G5 system since Apple will go the (W)intel route?
I know about Genesis/Pegasos PPC systems but the current ones uses G4s and the not-in-a-distant-future will use the PPC7448(?). But what about PPC970, can we expect them from Genesis aswell or does IBM or someone else make machines with them?
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 agree with you, but only to a certain point.
It might be okay to make the arguments you're making, except that Apple is increasingly marketing its systems as performance "serverish" machines in competition with other UNIX systems. I'm not saying that this is correct or incorrect, but that's how they're marketing themselves--and, based on what I see my colleagues purchasing, it seems to be working with some individuals. I myself have been thinking about migrating from Linux to OSX for many of the same reasons.
So, it makes sense to me to make the comparisons they did between Linux and OSX. Was it a perfect comparison? No. But it seemed reasonable.
I thought the article was extremely revealing, in that it suggested that performance bottlenecks were not due to hardware--as Apple has been suggesting--but rather, to software. It has really changed my view of the whole Apple/Linux-Power/x86 issue. It increases my confidence in IBM's line of chips a tad, and decreases my confidence in Apple's programming about just as much.
Would I like to see more, and more rigorous comparisons? Sure. But I think these comparisons were legitimate for many users who would be interested in OSX as an OS alternative to Linux for a performance system.
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.
Because intel is a one stop shop for apple. Apple can get xscale, wireless, nics, etc... and cpus. I dont think they can do that with amd.
You joke, but the binary format for Carbon apps is Mach-O.
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
It seems to me as though the article didn't point to a single weakness, but the fact that signaling, IPC and thread creation were all slower in OSX compared to linux. While it seemed clear that the threading performance was a bigger factor for MySQL, I can't help but wonder how much better all other aspects of OSX might improve if thread creation, signaling, and IPC were all improved.
Much as I would prefer to use OSX on a daily basis to windows, and somewhat prefer it to Gnome or KDE, it seems hard to escape the impression that Apple created an OS to run iSoftware (iTunes, iLife, etc.) and photoshop.
"We are all geniuses when we dream"
- E.M. Cioran
Unfortuantely you bought when Apple had just switched to Asus for their iBook's logic boards. Their first revs were complete crap. This is a problem that is related mainly to the G3s. The later G4 iBooks are very reliable, even though they're still using Asus boards. I set my parents up with one, and now they don't call for help like they had prior with their various PCs.
It's a bummer that you ended up with a lemon, if you would've spent a bit more for a Powerbook(They do not use Asus boards.), or bought later on when the G4 iBook were released, chances are that you would've bought a machine that is truly reliable. I've had my PB for 2.5 years now and after the first year I stopped shuting it down. I just sleep it now. The only time I restart is during an update. The last time I powered down was to install Tiger. Overall, my Macs are 99.99% reliable, the 2 PCs(One is a workstation) I have in my office for Rendering, are only about 60% reliable.
Apple will replace all iBook logic boards free of charge. The time I had to call Apple for support, was when my wives Powerbook's screen hinges were busted by accident, they sent a box the very next day, and when we finally got around to sending it back, the fixed Powerbook showed up a day later. I've never had any serious issues with my desktops that warranted an on-site call, so I'm not sure what Apple's turn around is? Macs in general require very little maintenance, but like any other hardware manufacture, like Dell, they're bound to ship a few lemons; Like my Dell Axim.
I have a couple of friends that "were" hardcore Linux PC peeps, they're on Powerbooks now and haven't looked back. I'm an artist, so besides the early dos days, I've always relied primarily on Macs, and only used PCs for support and games. No complaints here, Apple machines are simply more reliable on average than all the PCs I've owned and used.
Apple is moving to a successor to the Pentium M --not the Pentium IV. Anandtech are deceptive assholes, their speculatory comments about Apple's move to X86 intermixed with data about an irrelevant chip (the Pentium IV) is just their opening volley in a war against Mac on Intel. You see, a $500 macMini (wether it is G4 or Pentium M based) satisfies the needs of 98% of PC users. This will soon become more evident and sites like Anandtech and CPU (there for those in the 98% who now build their own PCs) will become obsolete until they can graduate from college (expand their education enough) to be relevant to the 2% of high-end users.
As opposed to monolithic kernels, where bugs are unusual?
BTW, there's not much "microkernelish" about OS X; it's not as if the kernel's spending lots of time sending messages to random server processes to implement every system call - that code path is a Boring Old Monolithic Kernel code path.
What I like about it is the granularity. When you are responding to a message, you are in control until you go back to the queue for the next message, effectively doing a yield to other processes until you are given the next message. That way you don't have to worry about locks, and semaphores, and protecting "this data structure" while worrying if it is OK to not protect "that data structure." Of course you still have to worry about callbacks into your code changing your state and resources in an unexpected way, but if you don't make a function call that triggers a callback, you won't have any preemption, deadlock, or race conditions to worry about. And if you make such a function call, the callback takes place at that call instead of any old place like with preemption.
Even when preemptive multitasking is added, all of the setups I have seen (mainly Windows and Java Swing, but I believe this true of Linux window managers), the GUI is still single-threaded so you don't need resource-protection locks out the wazoo for all of the resources used by a GUI (window object, graphic-contect (GC) object, font object, etc). If you run multiple threads, you sync with the GUI thread through PostMessage() and SendMessage(), which apply the proper synchronization locks to the GUI message queue. Java has the exact same thing only GUI objects have InvokeLater() and InvokeNow() (or something like that) synchronization methods which work exactly like PostMessage() and SendMessage().
When I first experimented with threads under Windows, I noticed that the granularity of time slices was much chunkier than with a well-tuned cooperative multitasking approach. I could never get the thread priorities to do what I wanted. I got the best result when I used the preemptive multitasking in a cooperative manner -- I made sure that a thread did some state update quickly and then did a Sleep() or did a Wait() on a signal object -- this works just like cooperative multitasking where you work quickly in response to a message and then do a yield when you dip back into the message queue for the next message. The Windows preemption scheduler is just too coarse grained and too clunky and the only way to get good performance with threads is to treat them like coroutines which yield to one another at explicit synchronization points.
Given that even with preemptive multitasking I was depending on cooperation of tasks (getting a signal, doing something quickly, and then blocking that thread waiting to be signaled again), the one stumbling block on Windows is disk I/O. The only reason disk IO has gone away as a problem is the computer and their disks have gotten so fast that you don't notice Windows being a hog on disk I/O. Yeah, yeah, Windows has asynchronous file I/O, but how does that help you with the "hidden I/O" of page swaps?
I wouldn't even need preemptive multi-threading if Microsoft would have gotten just one thing right. If you write your own message loop, you can do idle-time processing to do animations and updates -- essentially writing your own scheduler for a state machine model of those animations and updates. The dang trouble is that if you pop up a message box or even if the user holds the mouse button down on a menu selection, your state machine grinds to a halt because Microsoft patches in substitute message loops for message boxes and menus, even though they scold you if you write a multi-message loop modal application.
To get around this, I have used an "idle time" thread that keeps feeding the GUI thread with PostMessage(WM_USER) to do the animations and other updates -- this allows any message loop, including the unoverridable ones in menus and message boxes to run the animations. This takes a bit of work to get right -- your idle time messages have to be made lower priority than window messages so you don't gum up the