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
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.