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.
Maybe because Anandtech runs there whole site on MySQL.
Maybe because MySQL is where they have the most exp.
Maybe because they have a huge database and testing tools already setup for there main site they can use for testing, which again is MySQL
Why do the testing with MySQL? Ohh I don't know Maybe they just can
Personal Website
It's not a bug.
It's just that unlike pretty much everything else out there Apple GUARENTEE that fsync won't return until the drive has actually written the data to disk, not just to its cache. To do this they require specific drive firmware from their vendors. In their docs they point out exactly how to stop this, it's just that mysql obviously made the decision that data integrity is more valuable then speed.
(Oh, and OS X's task switcher sucks)
/* FUCK - The F-word is here so that you can grep for it */
It's not a bug.
:-/
I was referring to the bug in MySQL, not the Mac. The Mac's behavior is correct. That's why PostgreSQL works fine. MySQL relied on Linux-specific behavior, and got burned.
In their docs they point out exactly how to stop this, it's just that mysql obviously made the decision that data integrity is more valuable then speed.
Just be glad that we get secure data out of MySQL at all. Last time I tried to install MySQL on my Mac, there were big warning signs all over the place saying, "The Mac is buggy, your data is not safe! Run away, run away!" Of course, then an Apple guy stepped up and pointed out the fact that fsync worked exactly as it should, and that MySQL needed to fix their code. They've changed the code for better data security, but AFAIK they still haven't optimized for "correct" data integrity behavior.
Oh, and OS X's task switcher sucks
Amen. Drives me nuts, too, because the FreeBSD switcher really wasn't that bad. Here's hoping that Apple gets that fixed one of these days.
Javascript + Nintendo DSi = DSiCade
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
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
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.
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.
Except that people who implements M:N-style threading like mac os x believe that it can be fast (reasonabily fast)
Not having achieved it (still) is a "achilles heel" indeed. Apple has to work on that and make their threading implementation performant
There's a very good post from Ingo Molnar explaining why linux chose 1:1 and not M:N, and he points out a possible "users-space threads" issues:
"Plus there are other issues like security - it's perfectly reasonable in the 1:1 model for a certain set of server threads to drop all privileges to do the more dangerous stuff. (while there is no such thing as absolute security and separation in a threaded app, dropping privileges can avoid certain classes of exploits)"
Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs
Almost.
The binary format of Carbon application is either CFM or Mach-O.
CFM was the binary format of Mac OS "classic".
Mach-O is the native binary format of Mac OS X.
When the OS loads a CFM application, it does so through a "LaunchCFMApp" process instance wich loads the CFM binary and links up in one huge vector table all the system calls being made to Mach-O libraries (including Core Foundation & Carbon).
A CFM application is therefore double-inderected for all system calls.
Mach-O Carbon applications though are not all that common. Anything that still supports Mac OS Classic will be in CFM. There's not that much advantages at moving your CFM application to Mach-O unless it's to remove the tiny (and I mean tiny) burden of dealing with cross-format boundaries. There's not a performance penalty worth mentioning at being CFM, unless you're dealing with quick load time.
Cocoa applications are invariably in Mach-O format. So are, too, any unix tools underneath.
Off-topic:
Given that all of Apple's tools (and binaries for that matter) are Mach-O, it's easier to debug a Mach-O binary, unless you stick with CodeWorrior (did I misspelled that? Oops!).
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.
Precise, but wrong. You have it backwards. Mach is a message-passing microkernel, written from scratch that runs directly on top of the hardware. For compatibility reasons, and to have a usable OS to show off that uses it, the CMU group wrote a BSD 4.2 "personality" that runs on top of the microkernel. As I understand it, this contained big chunks of the BSD kernel code, and all of its userspace.
It was this software (the microkernel and BSD personality) that NeXT used as the basis for NeXTStep which begat OpenStep which begat OS X, which re-incorporated (a 10+ year re-synchronization from a different branch?) the userspace from FreeBSD.
No, we are running the schools site off a Dual 2GHz G5 with 2gb RAM because its the best machine we got, it just happens that it also is used for Dreamweaver, of which it works great for at the same time as its webserving.
"Again, we are focusing on workstation and server applications" Their bolding, not mine.
They also state...
"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." Again, their bolding, not mine.
It certainly seems they are discussing OS X as a server.
As to your second point, they probably had a G5 box handy. The CPUs and motherboard archetecture of the Xserve is pretty much the same as the G5. Heck, the Xserve even uses the same serial ATA hard drive system as the G5 instead of a SCSI system many other vendors would use in their servers. The only real difference between the two systems is their form factor and video cards. For the purposes of this article, I think those can safely be ignored.
The article certainly has plenty of flaws, but testing OS X as a server (vs desktop) isn't one of them.
It's not easy to find raw sales numbers, but here goes:
AMD sold 36 million processors in 2004.
They are opening the new Fab 36 in 2005/06, which should roughly double AMD's production capacity (their two current 8-inch fabs produce less than the new 12-inch fab can).
Intel should have 375 million per year capacity in 2005/06, thanks to 5 new 12-inch fabs.
Apple's sales in 2004 were about 3.3 million computers.
So, you do the math: roughly 5-10% of AMD's capacity (depending on how troublesome Fab 36 is) is a pretty big drop in the bucket, especially since AMD is currently so stretched to meet their current supplier's demands that they're outsourcing chip production.
But, for Intel, who should increase capacity by a huge jump in the next year, Apple is no strain.
Man is the animal that laughs.
And occasionally whores for Karma.
lmbench isn't testing threading; it's testing forking. These are NOT THE SAME on all *nix OSes. Yes, the Linux model may be better --- Sun is switching to a similar model --- but on Mac OS X, fork =/= thread. Not even a little. Not even half.
Yes, Mac OS X has lousy fork performance. Yes, this is a problem. No, that doesn't say anything about thread performance. Which might be lousy or wonderful, but is probably lousy.
That said, you can pry my Powerbook out of my cold, dead hands. I'm looking forward to x86 Powerbooks, too...
"And geeks are *still* switching to Macs in droves."
Some are switching back.
I switched and then switched back not because Linux is technically better but because of the reliability problems, hardware and software. The performance and lower prices are a bonus.
For example, my G3 iBook had about 10% downtime from all the bad logic boards and a few other things (eg they were out of replacement power bricks). I've also had problems with bugs and updates that break things. Some Linux distros are bad about this as well (eg Gentoo), but others are much better than OS X (eg Debian).
Some PC OEMs make better support than Applecare available. For example, Dell offers next-business-day or even same-day onsite support. In the alternative, a user can take responsibility for themselves and get instant service every time.
Ultimatley, I found that Apple simply didn't make a machine I could rely on.
I rarely criticize things I don't care about.
Look, we know it has a problem around process creation. That's not been news for a very long time. Where am I in denial about this?
My only comment amounted to wondering what the basis was to believe that this benchmark tested thread creation performance, which is distinct from process creation performance. Heck, I even said I was sure that thread creation performance was terrible. But this benchmark didn't measure that.
Saying that process creation includes thread creation is fine and good, but unless you can tell me what the additional hit is for process creation versus thread creation, you haven't said much of anything.
To make a thoroughly outlandish analogy, what if you were measuring how long it took to click on a URL, and you included the time to install and configure the operating system in that? It's a compound operation, admittedly not as closely-tied as the operations in thread/fork but a compound operation nonetheless. You could tell me it's absurd to measure the OS install time, and I'd agree --- but using fork() to measure thread creation time is equally bogus, if more subtly so.
Process creation is hardly the slowest part of Mac OS X; I'm having serious issues with its memory management, too. And I want that problem to get fixed, and I want the fork performance to get fixed, and if there's a thread creation performance issue that needs to get fixed (which I'm sure there is, though these benchmarks did nothing to alter that belief one way or the other), I want that fixed, too.
But knowing you have a problem is a question distinct from measuring that problem. The original article may be correct in knowing that there's a problem with thread creation, but it did nothing to measure that problem.
Well Oracle 10g seems to be pretty good:
... not IBM with AIX, not Hewlett Packard with HP/UX, not Sun with Solaris, and not Dell with any operating system can match the Apple OSX/Darwin technology and price."
http://www.psoug.org/rac_on_mac.html/ rac on mac.
These guys have no mac bias, the dba who did much of this config regularly deploys very large systems for Boeing, etc.
And they find; "In the 64bit technology space no company