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.

Comments

Neon Lights Help

[Anonymous Coward]

It is clear that if you plan to run MySQL on Apple hardware, it is better to install YDL Linux than to use OS X. If you need excellent read performance, the maximum performance of your server will be up to 8 times better.

I also find that neon lights and a clear side panel with a dragon decal on it helps.

Re:Neon Lights Help

[justforaday]

You joke, but the binary format for Carbon apps is Mach-O.

Re:Neon Lights Help

[MouseR]

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

MySQL?

[AKAImBatman]

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?

Re:MySQL?

[cyberlotnet]

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

Re:MySQL?

[laptop006]

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)

Re:MySQL?

[AKAImBatman]

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.

Re:MySQL?

[AKAImBatman]

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!

Re:MySQL?

[fimbulvetr]

This sounds like a flat out lie from Apple. Not the kind of behaviuor you should expect from a *nix vendor.

Uhh, you've never worked with Sun Microsystems, have you?

Re:MySQL?

[squiggleslash]

Because the entire point of the article is to work out why it doesn't work! Trying to work out why MySQL doesn't work by ignoring it and using PostgreSQL instead isn't going to get you many useful answers. Useful analogies:

• You bring your car to a mechanic. You come back later to ask the mechanic what was wrong, who promptly tells you he found your car didn't work so he drove an entirely different one instead (Obligitory Slashdot Car Analogy)
• The Director of FEMA finds that New Orleans is under water. So he evacuates Chicago. (Obligitory current affairs analogy)
• There's a problem with the lock on your door. You bring in a locksmith, who asks why you don't just go in through the window? (Obligitory locks on house Analogy)
• You go to Wendy's and find a finger in your chili. So you sue MacDonalds (Obligitory reference to poorly understood lawsuit Analogy)
• Your computer program runs slowly and inefficiently. So you rewrite it in Python (Obligitory, probably justified, attack on Python Analogy)
• You're trying to work out whether "The Brothers Grimm" is a great movie. So you read the reviews of "Harry Potter: Revenge of the Sith" (Confusing movie analogy)
• You feel the country needs a better President, one with experience and an understanding of wars, one with the ability to engage others and move this country forward, to seek and resolve conflicts peaceably where possible, one that strongly believes in personal freedom, in freedom of thought, one that copes with national disasters and can unite the country in even the worst of circumstances - so you vote for George W. Bush, again (Obligitory (justified) Bush Bashing Analogy)
• You don't understand why your dog will not eat the dog food you got him, so you get a car. (Obligitory other/miscellaneous Analogy)

I hope all those analogies helped. Let me know if you have any problems.

Re:MySQL?

[cyberlotnet]

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

Re:MySQL?

[keytoe]

Why don't they throw PostgreSQL in there and see how it performs?

Actually, if you have the Apple Remote Desktop Admin tools installed, you do have PostgreSQL installed. Only you don't have full access to it!. ARD uses it to store any collected stats you've pulled from your ARD clients - and they even provide you with directions on how to access that DB from outside ARD (eg, from a command line script). So far, pretty cool.

Unless, that is, you actually want your own installation of PostgreSQL for other purposes. I've had it installed on my laptop for years as I do web development with it. It suddenly stopped working after I installed the latest ARD tools. You see, Apple installs PostgreSQL configured to listen on the default port, and then doesn't allow you 'root' access to it. They give you the password for the ARD account, and you can change that database - but if you need to create your own database with your own users, you're out of luck. And since they're using the default port, you have to change your port to get an alternate installation up and running.

This just irks me. If they want to start including PostgreSQL in the standard installation, that'd be cool. But there damned well better be a way for me to manage it. If they're going to install it buried inside the ARD Admin bundle, then run it on a private port.

Re:MySQL?

[Bun]

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.

Re:MySQL?

[disappear]

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

Re:MySQL?

[disappear]

but come on; its blindingly obvious from Anadtech's testing that Mac OS X has got a performance problem around processes/thread creation.

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.

I am of two minds regarding this

[aftk2]

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

Re:I am of two minds regarding this

[bad_outlook]

"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)

RE: IBM vs Intel....arg...

[fshalor]

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. ;)_

Where are the workstation tests?

[Durandal64]

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.

Re:Where are the workstation tests?

[Red Flayer]

"At the desktop level, no one's going to be working with thousands of simultaneous threads.

Although, that would explain the quality of /. moderation.

jk... I think it works quite well in general.

Re:Where are the workstation tests?

[Anonymous Coward]

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.

Re:Where are the workstation tests?

[diegocgteleline.es]

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

Re:Where are the workstation tests?

[andyross]

Mac OS X adds an extra layer of communication for threading, so you can have user-space threads. [...] In Linux, everything is a kernel thread. [...] 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.

This sounds very authoritative. But it makes no sense. What do threading models have to do with security? What does it mean for a thread to "run amok in the kernel", and how would I do that if I wanted to?

I think what you're trying to say is that Apple's M:N threading model prevents user-space threads from wasting kernel resources, which is a common argument. But since the benchmarks (lmbench, at least -- ignore the flawed MySQL stuff) show that the kernel is significantly slower, the argument just falls down. You can't argue that it's OK to waste resources to prevent the waste of resources when the clear numbers show a net loss. The M:N complexity gets you nothing but overhead.

Re:Where are the workstation tests?

[andyross]

If a malicious process is spawned from an infected one, it's confined to the user-space. In Linux, a kernel thread doesn't have a distinct address space relative to any other kernel threads.

This is just plain incorrect. You have been misinformed. (And who modded that up? Shame on you.)

Both OS X and Linux threads share the parent thread's address space in exactly the same way. Both OS X and Linux subprocesses (malicious or not) are denied access to the parent process's address space in exactly the same way. There are no meaningful security implications between these two architectures.

The sole difference between the models is the issue of scheduling (when threads get to run, and when they must give up the CPU): under Linux, all threads are scheduled preemptively by the kernel. OS X uses a more complicated model where M user-visible threads are mapped onto N kernel threads; the idea being to limit the number of "expensive" kernel threads while preserving the benefit of preemptive scheduling. (Except that in practice, such systems end up introducing more overhead than they save.)

The OS X thread model is a performance optimization (or, in this case, bug). It is not, and never has been, a security decision.

Fork and IPC times

[Visaris]

The most interesting parts for me were the fork() times and IPC benchmarks. 0SX was considerably slower in these areas. Is this an nptl issue?

Real world performance

[Anonymous Coward]

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.

Really...

[Otter]

So, as we get to know the strengths and weaknesses about this complex but unique OS, we'll get insight into the kind of consumers who would own an Intel based machine with Mac OS X - besides the people who are in love with Apple's gorgeous cases of course....

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.

Re:Really...

[LurkerXXX]

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.

That's all nice and all for you, but Apple does sell these things the call XServe's that are supposed to be "servers". And they run an OS called OS X "Server". Some of us really do run servers and it's informative to us for deciding if we should include a G5 or OS X Server as an option for new servers we need. I'm terribly sorry it doesn't interest most Mac users, but it certainly interests some of us. If you don't care, just skip the article.

Re:Really...

[LurkerXXX]

As to your first point, lets see, on page three where they discuss what their setup was they say...

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

Hrmmm

[BlueGecko]

I always get nervous whenever I'm reading something that's a bit over my head but seems to make sense, and then I come to something where the author has no idea what he's talking about. On page 7, the author writes:

Readers pointed out that there were two errors in this sentence. The first one is that Mac OS X does use kernelthreads, and this is completely true. My confusion came from the fact that FreeBSD 4.x and older - which was part of the OS X kernel until Tiger came along - did not implement kernelthreads; rather, only userthreads.

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.

Re:Hrmmm

[AKAImBatman]

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

Re:Hrmmm

[andyross]

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.

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.

Re:Hrmmm

[AKAImBatman]

Not quite. It was a bit more complicated than that. Net/1 and Net/2 (the later being fairly complete) was a version of 4.3 BSD that was free from licensing issues with USL. Supposedly that's what triggered the lawsuit.

4.4 was the branch that split into the Lite and Encumbered branches. Most BSD development from that time has progressed from the BSD-Lite branch.

More Info Here

What most people think of when they think of 4.4 as being the first unencumbered version is that the settlement with USL explicitly protected users who used 4.4 and higher.

Interesting, but let's sum it up:

[MikeyTheK]

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.

Re: IBM vs Intel....arg...

[Courageous]

...Why intel?...

One word: laptops.

C//

Software

[jacklexbox]

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

Re:Software

[jacklexbox]

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.

Non-Apple G5 hardware

[aliquis]

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?

iSQL

[RUFFyamahaRYDER]

No worries... Apple will come out with iSQL and things will be all better.

Re:iSQL

[RUFFyamahaRYDER]

iSorry... =(

Re:iSQL

[drewness]

That's because MS SQL is essentially just Sybase for Windows.

i'm confused ...

[SamSeaborn]

I looked at the article, but I'm confused. Where's the pretty graphs showing that Mac is better than Windows?

Sam

priorities

[diegocgteleline.es]

Apple has priorities. Just like linux sucks on desktops and rocks on servers, Mac OS X sucks on servers and rocks on desktop

Re:MySQL and other animals...

[RzUpAnmsCwrds]

It has nothing to do with FS performance and everything to do with the fact that Apple's implementation of threading has considerably higher overhead than Linux.

Wait, WTF?

[mcc]

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.

Why Apple Didn't Choose AMD

[WombatControl]

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.

But there's so much more!

[Mr. Underbridge]

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

But there's so much more here at slashdot! Let's add "Companies are also suing other companies over patents/trademarks/copyrights they don't actually have." That covers SCO and the recent LMI stories.

We also have the occasional:

"Somone built a PC out of weird parts,"

"Big brother gained new, over-reaching powers that will bring society to its knees,"

"Some OSS figurehead (Stallman, Raymond, etc) said something idealistic/naive/irrelevant/stupid/arrogant,"

"Researchers at a small University made some irrelevant, impractical advance in so-called nanotech that will never affect anyone but makes us crap our pants,"

"Europe is far more enlightened than the US because...,"

"Some government switched from Windows to Linux,"

"Some government used Linux as a ploy to get cheaper Windows pricing,"

"Someone at Google farted,"

"Roland Piquepaille got a story on his 'blog' accepted by ripping off the AP feed,"

"Fudged TCO studies show that OS 'A' is cheaper than OS 'B,' and far cheaper than OS 'X'..."

"Microsoft is still evil,"

"An exploit is discovered in Windows that allows...,"

"Will we be able to do in 100 years some ridiculous thing that I've read about in tons of sci-fi novels but is completely pointless in real life?"

... etc. Yes, this is our slashdot.

Re:Features vs speed

[callipygian-showsyst]

Apple has always been about features at the cost of some speed.

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

Re:MySQL and other animals...

[revscat]

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.

More and more I consider the "Mac users are primarily photoshop users" to be somewhat of a strawman. I work at a Java shop, and many of our programmers, myself included, use Macs. So does our change management guy and much of netops. Yes, the graphics designers use Macs, but Macs are used throughout the company by many people for different reasons.

And now a word from...

[Anonymous Coward]

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.

well...

[diegocgteleline.es]

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

Why not write a pthread() benchmark?!??!?!?!

[javaxman]

I'm sorry, I generally love AnandTech, but...

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

Re:Why not write a pthread() benchmark?!??!?!?!

[Guy Harris]

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.

Heck, it'd not be shocked if fork() on Linux had extra overhead that pthread_create() didn't. It might, for example, be duplicating the address space; fork() is copy-on-write (on most if not all UN*Xes, including OS X and Linux) so that the data in the address space doesn't get copied, but the address space data structures might have to be duplicated, and resident writeable pages would have to get marked non-writeable in the MMU so that an attempt by parent or child to store into them would provoke a copy.

OS X lacking

[MECC]

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.

Re:OS X lacking

[ArbitraryConstant]

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

Unlikely ..

[BeanThere]

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.

Re:Not A Good Benchmark

[prockcore]

Aparently neither does Apple. Since OSX Server comes with MySQL, not Postgres.

Re: IBM vs Intel....arg...

[mihalis]

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 for any platfor

[greymond]

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.

Re:Avie Tevanian & the CMU Mach Microkernel

[mclaincausey]

I think I can help out here a little bit, with the Mach side of things. First, we should realize that this is a hybrid kernel (XNU being Mach/BSD): we shouldn't just assume every single system task falls under Mach's and not BSD's domain. As it happens, IPC is in the domain of Mach in XNU, so this point is moot in this particular thread, but I thought I should point it out in case others make assumptions. Here's what Mach does in XNU, for the record: preemptive multitasking, kernel threads (pthreads map to kernel threads), memory protection, VM management, IPC, interrupt management, real-time support, kernel debugging, and console I/O.

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

There are bugs, sure, but these aren't them.

[g_lightyear]

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.

Re:There are bugs, sure, but these aren't them.

[g_lightyear]

For just a second, step back.

Apple's not special, and just like every other vendor, they ship bugs. And just like every other vendor, they build, test, and ship the applications that come out in a pretty identical way you get to when you ./configure && make install.

So, here's the question: Are we talking about the operating system, or someone's ability to run ./configure? Are we talking about "Apache being slow", or "the bog standard install being slow"?

Because, for a moment, I thought the whole point of the article was to point out the huge, gaping flaws in the kernel - and someone with the right nail (let's point out the flaws in a kernel) ended up with the wrong hammer (let's run a bunch of applications that don't behave well in standard installs or are old enough to be missing important dev fixes.)

Nowhere did I strain to stick my nose up apple's arse - yet your reaction says it all. You're not actually interested in the point of the article, either, and neither was the author.

You're just looking for a way to stick it to Apple for being crap.

Congratulations, you're a winner - Apple's just another OS vendor, shipping just another set of unusual bugs around, just like the FreeBSD it's built on. It's got a 'colourful' TCP implementation, just like FreeBSD, it's got bugs, just like FreeBSD, and it's got its problems with overhead on PPC, just like FreeBSD.

And Linux 2.4, which also had that TCP bug for a while. And 2.6, which now has a different one. Because, quite frankly, if we all wanted the perfect OS for performance, we'd all be running Solaris, wouldn't we. They don't *ever* get bugs in their kernel.

Wanker.

Re:There are bugs, sure, but these aren't them.

[g_lightyear]

If that's what you're expecting, then you're going to be disappointed to find out that every OS vendor ships bugs in their server operating systems, and that every application developer ends up having to do work to make sure that their applications avoid those bugs.

All of us.

So this whole "OS X sucks as a server" thing can be justified on a lot of grounds, but NOT THIS ONE. Cry more about how bog standard vendor installs aren't high performance monsters. Cry more about how application developers shouldn't have to work around bugs in vendor operating systems.

Then go back to Basic on your Colecovision, because that's probably the only OS I can think of that didn't ship with one.

Re:There are bugs, sure, but these aren't them.

[Guy Harris]

And bugs aren't unusual. It is the cost you pay when you use microkernel.

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.

Re:There are bugs, sure, but these aren't them.

[g_lightyear]

TCP_ would be the reason that the TCP related portions of his tests - you know, "apache", and "mysql", and stuff - sucked.

As for the "microkernel"... You do know it's not Mach in microkernel mode, right? It doesn't mean it doesn't have its problems, but it does mean that Mac OS X doesn't have a microkernel.

There are bits that suck - but these aren't them.

Re:Fab capacity -- or not?

[default luser]

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.

Apple's poor choice of using "Asus."

[JackAxe]

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.

Message passing-cooperative multitasking

[Latent Heat]

I know it gets slammed as "just so 1980's", but cooperative multitasking based on responding to a message queue as a way of writing GUI's is one of the great ideas.

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