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

[oringo]

That explains why OS X runs a MACHo microkernel...

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

Re:Neon Lights Help

[soft_guy]

It is possible to include both a CFM and a Mach-O executable in the same application bundle. The Mac-O executable will be launched on MacOS X and the CFM executable will be launched on MacOS 9. I have delivered commercial software in this manner.

Re:Neon Lights Help

[Rosyna]

Mach-O may be the native OS X binary format, but PEF/CFM is the Native PowerPC binary format. In other words, things that use the PEF Binary format have the potential to run much faster. Of course, all of this is negated if you use GCC to compile your binary. It just sucks at PowerPC code.

Re:Neon Lights Help

[MouseR]

What the hell you're talking about?

There's no "native PowerPC" or "Native Intel" binary formats. It's all just binary data dumped into a file. How this file is organized means only something to the operating system loading it. Not the CPU. The CPU doesn't care where the data segments is. It doesn't care where the content lies within the file. It's not going to load it and parse the damn file itself.

All it cares is the in-memory address or what's to execute.

PEF (long deprecated) and CFM were formats devised for use the the classic Mac OS system. It's nothing to do with any specific CPU requirements. It's simply a standard way to package your binaries so the OS knows what to do with them and how to access them.

The truth of the matter is, any CFM app runs slower in Mac OS X. Not much slower. Perhaps not noticeably slower. But any system or Mach-O library call will end up requiring two jumps to get to it so either way you look at it, CFM apps WILL be slower than Mach-O. but again, it's got nothing to do with the CPU. It's the managing OS underneath and how everything else is linked as.

As far as GCC's PPC code generation, same goes for Intel. If you want faster generated code, you go either CodeWarrior or IBM's XL for PPC, or go with Intel compiler (icc?) for Intel hardware.

It's got nothing to do with the binary format. Other than not having to doubly-inderect system calls if you're linked as CFM.

Re:Neon Lights Help

[Rosyna]

I'm more curious as to what you're talking about. CFM can only exist in PEF Binaries on OS X (well, no other compiler compiles CFM into Macho binaries). And CFM is the native PowerPC format as it uses the $r2 register and doesn't use PC relative addressing. Macho/dyld ignores the $r2 register completely and uses PC relative addressing. The PowerPC doesn't support PC relative addressing so there is a speed hit every time a process accesses static or global data. There is also a speed hit for function calls. Granted, CFM has this function call overhead too, but it only incurs it once. Macho incurs the overhead *every* time. Because this speed hit doesn't occur with CFM, CFM would be the faster method.

Macho/dyld were designed for CISC chips, but the PowerPC is a RISC processor.

we just got one

[Anonymous Coward]

we just received one of the intel mac workstations at my office on friday, it looks just like the g5 ones (nice metal case). non-relevant, but i can't wait to do some of my own tests.

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?

[tokki]

Everying single time...

if (DB == "mysql") {
      whyNotPostgreSQL();
}

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?

[AKAImBatman]

Uh, no. My point was not PostgreSQL specifically, but rather that MySQL doesn't work so why not try something that does?

MySQL has its uses, but if it's broke, either fix it or try something else.

Re:MySQL?

[theJML]

Why do they insist on MySQL? Because MySQL is the self proclaimed "World's Most Popular Open Source Database"... I think it would be interesting to see how other SQL DB's run on the system, but then I supposed it would have been a DB speed article instead...

Re:MySQL?

[Anonymous Coward]

So I guess that makes MySQL the the N*Sync or Britney Spears of the database world.

Re:MySQL?

[LizardKing]

mysql obviously made the decision that data integrity is more valuable then speed.

That would be a first for MySQL.

Re:MySQL?

[Anonymous Coward]

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

Probably because PostgreSQL is slower than shit.

Re:MySQL?

[Anonymous Coward]

Notices that they don't just say "mac os x sucks", they actually analize the problem (networking latencies, etc) , looking at apple's documentation, run other benchmarks (lmbench)

Anyway, it's just a problem of disk trhoughtput, it's not a secret that mac os x's has some high-performance problems in servers, even in the apple documentation they state how their "funnels" are coded, far from the fine-grained locking that linux - and NT, for that matter - uses, which makes it fall behind a bit on SMP environments.

And correct me if I'm wrong, but ext3's fsync wasn't fixed some releases ago, with "barriers" for jounraling safety and everything?

Re:MySQL?

[Anonymous Coward]

Fucking Apple zealots... how is this off-topic? It's about Apple's move to Intel... and their new machines.

Re:MySQL?

[Bun]

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?
Because they wanted to find out why it has problems on the Mac. And they seem to have found the answer in the way OSX handles threads.

Re:MySQL?

[Lussarn]

So, show us the numbers on PostgreeSQL. Judging from the fact that OS X can't even handle Apache (According to the article) the problems seem to be a bit deeper than a fsync bug.

Apple told us that the problem lies in Apachebench (the client side), which stalls from time to time and thus generates too low of a load on the (Apache) server.

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

Re:MySQL?

[akac]

So here's my question - has anyone written a patch for MySQL's source that us Mac users can apply and recompile to make it faster?

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?

[AKAImBatman]

No, they *think* the problem is threads. As another poster pointed out they're still plenty clueless about what's actually going on. Until they elminate a few more factors (such as software that doesn't work), they might as well make completely wild guesses.

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?

[Anonymous Coward]

Got burned? I'm sure they don't give a fuck.

Re:MySQL?

[metamatic]

it's just that mysql obviously made the decision that data integrity is more valuable then speed.

That'd be a first. Next thing they'll be implementing ACID features. Where will it all end?

Re:MySQL?

[AKAImBatman]

Really, squigglesquish. That post is just *bad*. (Not to mention quite offensive to quite a few different groups.)

If you want to pull the analogies trick, then let's at least get *one* right (the car reference). If a mechanic sees that he's getting low voltage in the car immediately after installing a battery, doesn't it make sense to try a different battery? If a different battery has the same problem, then you can safely eliminate the battery as the cause.

Re:MySQL?

[Lussarn]

Yes I have, I can see you point. But Solaris at least can run Apache with descent speed and mysql has at least in the past been targeted first for Solaris. It's not only Linux it runs good on.

Re:MySQL?

[Anonymous Coward]

Try and RTFA - fsync() was not an issue.

Re:MySQL?

[eyegone]

...mysql obviously made the decision that data integrity is more valuable then speed.

When has MySQL ever done that?

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?

[Anonymous Coward]

Try Witch. It's highly configurable and quite an improvement over the default task switcher... and can be used in conjunction with the default.

Look for it on VersionTracker.com

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?

[Anonymous Coward]

If I'm not mistaken, the grandparent and great-grandparent were referring to the kernel task-switches, not switching between windows. Task switching in the kernel is when the processor moves from one thread or process of execution to another. Mac OS X tends to have some problems in this area.

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?

[fimbulvetr]

Well, then we're both on the same team. I've ran Apache and Mysql both on Solaris for years, and they perform just fine. It'd be interesting to see Solaris vs. Linux on scalability of clients, though. I think Linux would be faster, more secure and ultimately the best choice, but I would guess that Solaris could handle more simultaneous connections.

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?

[Anonymous Coward]

Nah, Britney have *some* integrity.

Re:MySQL?

[Anonymous Coward]

Maybe because Anandtech runs there whole site on MySQL.

If this were true, you might have a point, but since it is not, you do not.

Also, it's "their".

Re:MySQL?

[Bun]

lmbench isn't testing threading; it's testing forking. These are NOT THE SAME on all *nix OSes.

True. And I think PowerBooks are cool, too... but back to the issue at hand.
If you would RTFA:

" Readers also pointed out that LMBench uses "fork", which is the way to create a process and not threads in all Unix variants, including Mac OS X and Linux...
The process creation is done with fork(), but fork() is nothing less than a clone() without the flags that describe the resources that must be shared. So, if you test fork() on Linux, you also get a rough idea of how fast threads are created...
What about Mac OS X? Well, when the Mach kernel is asked to create a Unix process (fork()), the mach kernel creates a task (which describes the resources available) and one thread. So, thread creation time is included in the fork () benchmark of Lmbench. "

Any questions?

Re:MySQL?

[disappear]

Yes: why the necessity for this pathetic and not really all that correct justification for what is in essence a synthetic benchmark when a different synthetic benchmark would do just fine?

Re:MySQL?

[cahiha]

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.

It's nice that MySQL developers went through the trouble to accomodate OS X, but MySQL wasn't broken before they did. Linux applications don't necessarily run on OS X--just like OS X applications don't necessarily run well on Linux, or run at all on Linux. In fact, OS X is full of system-specific (mis-)features portability problems, and most Macintosh software doesn't port to other platforms at all. And Apple is working on increasing the differences with things like Netinfo, HFS+, Spotlight, and init.

Apple likes to claim that OS X is "a better BSD" or "a better Linux", but the fact is that OS X is a different operating system; it isn't even derived from official UNIX source code, and its architecture is radically different from the BSD architecture (let alone Linux).

I'm sorry if Apple's marketing collides with reality, but those are the facts. And the fact that Apple is trying to make the Macintosh into a platform to which everybody can port, but from which nobody can easily port is not a good sign; in fact, it will hurt Apple big time in the long run.

Re:MySQL?

[Macka]

I really don't understand why you're in denial about all this. Yeah, I'm a big Mac fan too. I stopped using Linux and Windows at home 3-4 years ago, and I'm on my second PowerBook already (plus I use it full time for work now). And yes, you'd have to pry it out of my cold dead fingers ... but come on; its blindingly obvious from Anadtech's testing that Mac OS X has got a performance problem around processes/thread creation. And they should be congratulated for drawing this out into the open, because the more this gets noticed, the more Apple will focus on fixing it. And they will, because its already been done before, and because its only software. It also shows us that Mac OS X has yet to find its running shoes, which means that at some point in the not too distant future it will, and we'll get to feel the benefit of it.

Re:MySQL?

[Lars T.]

Because the entire point of the article is to work out why it doesn't work!

But sticking to your pet theory why it doesn't work and refusing to even check a possible different reason looks too much like a DA trying to get a conviction instead of the guy who did it.

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.

Re:MySQL?

[Guy Harris]

"...So, thread creation time is included in the fork () benchmark of Lmbench. "

Any questions?

Yes, three questions.

What work that's not done when creating a thread with pthread_create() is also included in the fork() benchmark of LMbench?

What fraction of the total work of fork() is the part of that work not also done by pthread_create()?

And, if a significant portion of the work done by fork()is not done by pthread_create() (or clone(), if MySQL is directly using clone()), how meaningful is a fork() benchmark if you're curious about pthread creation performance?

Re:MySQL?

[shaitand]

You're right, that benchmark did not conclusively point to a thread problem. In fact the article did not conclusively prove a thread problem. However, it showed extremely poor numbers in several benchmarks that all have thread creation and not neccesarily process creation as a potential factor.

The TCP benches that followed the lmbench fork based tests were more dependant on threads than processes and MacOS X dive bombed on them as well.

Either by itself means nothing, but when you have both a thread problem is sounding more and more likely.

Re:MySQL?

[Lars T.]

Any questions?

Yeah. Do you actually believe that is more than a lame excuse? thread creation time is included in the fork () benchmark of Lmbench - well, but so is a ton of other stuff, so don't pretend it's the same thing. Why does this guy believe they invented threads (aka light-weight processes) in the first place, so people could use processes to check how fast they are?

Re:MySQL?

[squiggleslash]

That's complete rubbish. Benchmarking PostgreSQL does not in any way help you find out why MySQL is slow.

If you're trying to find out why MySQL is slow, you need to work with MySQL. To stretch your analogy, this would be like a DA deciding that in order to find a murder suspect, it should investigate an entirely unrelated drug deal.

Re:MySQL?

[BorgCopyeditor]

Unless the mechanic has botched the first installation. Perhaps not an unfair analogy to these benchmarks.

Re:MySQL?

[Lars T.]

Oh, sorry, I thought we were talking about the Anandtech article, not something where somebody actually wanted to find out why MySQL was slow, as opposed to making the statement that Mac OS X was slow because MySQL was slow.

Re:MySQL?

[Alan Partridge]

"descent speed"?

What's that, terminal velocity?

Re:MySQL?

[Anonymous Coward]

I didn't know that.

Re:MySQL?

[Anonymous Coward]

Me neither.

Re:MySQL?

[TheRaven64]

Yes, the Linux model may be better --- Sun is switching to a similar model --- but on Mac OS X, fork =/= thread.

Are you sure? Linux just switched from a 1:N model to a 1:1 model for kernel scheduled entities to thread mappings. OS X inherits a 1:N mapping from Mach, which had a 1:N mapping from the start. Sun, on the other hand moved from a 1:N mapping to an M:N mapping years ago, and this is one of the reasons Solaris generally has better threading performance than other operating systems. Moving back to a 1:N model would be a step backwards.

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.

Possibly, although Mach traditionally has relatively good thread performance. Of course, the last time I looked into this was around a decade ago, so relatively good then might be relatively poor now...

Re:MySQL?

[mink]

I have to ask. Is "terminal velocity" 9600 BPS?

Features vs speed

[Anonymous Coward]

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?

Re:Features vs speed

[ArbitraryConstant]

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

Actually they're all about speed sometimes, but only when they have it.

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

er... what? That doesn't make sense.

As the article says, each application thread is also a kernel entity in OS X. Also, the number of windows has nothing to do with the number of threads. It doesn't really have anything to do with anything. A single-threaded application can have multiple windows and a multi-threaded app can have one window.

"By the report the G5 processors are just as fast as the fastest x86."

Slower on integer performance, memory latency, etc. About the same on floating point. Faster on vector. This isn't much of a shock. It depends on what you need to do, but I will note that the Opteron 250 did pretty well and that's not the fastest chip AMD makes.

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:Features vs speed

[Too Much Noise]

By the report the G5 processors are just as fast as the fastest x86.

Sorry, unsupported assertion. Opterons *50 aren't the fastest Opteron procs around, as some already pointed out. But nevermind that. Look at how gcc 4.0 lowers the x86 fp scores. Also, consider the fact that gcc 4.0.0 introduced changes in handling x86 vector code that apparently were not all for the better judging from the numbers (bugs too - see this one for instance) and that IBM made significant contributions on the Power/AltiVec side of gcc 4.

The one thing G5 seems to be doing better is fmadd - hardly a surprise, as SSE/SSE2/SSE3 have no single instruction equivalent. Otherwise, clock-for-clock the scores are not that impressive - and in fact, when using fdiv, some are rather weak: a 2.7GHz G5 about 25% slower than a 2.4GHz K8? Mind you, in raw flops a top-pumped Xeon would do better than the Opterons, too.

Re:Features vs speed

[Anonymous Coward]

I don't think their test even used SSE floating-point, which really is the way to go nowadays. I also don't think they vectorized the code for either x86 or PPC.

Re:Features vs speed

[Anonymous Coward]

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.

Or you could just buy Windows, which is based on the unique NT Client/Server Kernel that doesn't have to deal with issues like this, as the kernel sits under the 'client OSes', which are OS Subsystems. Application threads talk to the Subsystem kernel, which talks to the NT Kernel.

A very elegant Kernel design, no matter what you think of the Win32 Subsystem or the 'Windows Interface and Applications'.

That is why NT CAN run the UNIX Subsystem right along side the Win32 Subsystem (with the Win32 Kernel32.dll), using the same NT underlying kernel.

All without emulation or the performance cost that the Apple Kernel hooking bastardization uses to try to work around a monolithic kernel.

Also things fails like Kernel Panic which both the different OSX BSD and Linux kernels technologies are prone to do.

Re:Features vs speed

[Guy Harris]

Application threads talk to the Subsystem kernel, which talks to the NT Kernel.

...except when they talk directly to the NT kernel.

Also things fails like Kernel Panic which both the different OSX BSD and Linux kernels technologies are prone to do.

Yes, but neither of those systems are prone to blue screen halts. (Well, I don't think Linux's panic screen is blue.)

(I.e., the terminology might be different in NT, but the concept exists. Statistics on how often particular Linux kernel releases, OS X releases, and NT (including NT 5.x) releases die in the kernel might be interesting.)

Re:Features vs speed

[arose]

You can't rewrite history! (Well, you can, if you use the Wikipedia, but that's another topic.)

You can rewrite the article, but you can't rewrite it's history. :-P

Re:Features vs speed

[Lars T.]

But Steve Jobs said they were much much faster, before he caved in and switched architectures. You can't rewrite history!

And he hasn't said he was switching because x86 was faster. And Anand shows that they aren't really that much faster, and that the G5 actually has the faster FPU.

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:I am of two minds regarding this

[pixelgeek]

-- The first thing jumps to mind is a typical fanboy response

The next thing that jumps to mind is...

http://en.wikipedia.org/wiki/Straw_man

Re:I am of two minds regarding this

[BeanThere]

I should be able to go from prototyping my web apps right to production, without a bunch of migration or guesstimation.

I agree with you in principle, but in practice nobody should ever be doing prototyping on the production system - period. Anyone who is doing that (or even doing general desktop tasks) on a server system that is intended for heavy-duty use has bigger problems. It's true that Apple have "focussed their resources on" the end-user experience for desktop use rather than on optimising for heavy-duty server us, but I'm not sure that this really matters in practice, because the typical desktop user is not going to feel a difference at all - so just use Linux on the server, and OS X on the desktop.

Re:I am of two minds regarding this

[mikefe]

[...]"in practice nobody should ever be doing prototyping on the production system - period."

Agreed.

But that is not what the gp post was talking about. Production was a poorly chosen word, but understandable to most people. Why should you not be able to run a full production workload in your prototyping environment?

Re:I am of two minds regarding this

[njh]

"Where else can you get a great desktop environment that just works, along with a built-in Unix-like OS?"

Here: Ubuntu Linux

Re:I am of two minds regarding this

[TheRaven64]

Tiger introduced a lot of new features into the OS X kernel (full AIO support for example - Panther just allowed it on files). Apple's kernel team have a lot of work to do bringing the old Mach 2.5 / 4.2BSD based kernel up to date with things like POSIX. With Tiger they seem to have more or less finished the `make it work' part of the cycle. Hopefully the next step, `make it fast', won't take too long. As an aside, they get some quite nice things from the Mach heritage if they choose to use them. Mach ports provide a nice mechanism for upcalls from kernel to userspace - something seriously missing in most UNIX systems (Linux has an ugly hack to do this, but it's not a good solution).

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?

[Sesticulus]

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.

Actually it is news to some people because Apple would have you believe otherwise. XServes were on my short list of things to evaluate before these articles, my list is shorter now.

These were good articles for people in the market for those sorts of things.

Re:Where are the workstation tests?

[dchallender]

Problem is, it's not about thousands of threads - if it was that would not be too badits about a small number of threads. Read the article... Basic multithreading, in so much as a handful of concurrent threads work OK without huge performance hit, is still important on "desktops".
--
Cheers Dave
Generated by SlashdotRndSig via GreaseMonkey

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?

[digidave]

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

Um... what? Linux migrated away from userthreads because it sucks. OS X has also migrated away from userthreads and now uses kernelthreads. Both use pthreads.

"The author made a fundamental mistake in assuming that server stress tests were the be-all and end-all of performance computing"

No, the previous article benchmarked both and found that OS X performed better as a workstation. The entire point of this article was to try to determine if it was OS X or the CPU that was responsible for poor server performance.

Re:Where are the workstation tests?

[TheSkyIsPurple]

I regularly run a script which interrogates all of our Active Directory Domain Controllers simultneously, and my poor machine comes grinding down... (>50 ldapsearches at once) I have to run as root or I run out of processes I go for a walk while it runs, because my Dual-gig machine is nearly unusable while the script is running.

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?

[Durandal64]

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?

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.

Re:Where are the workstation tests?

[Durandal64]

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.

Ah, but to turn your previous argument against you, AnandTech did bill it as "No More Mysteries". :)

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.

Like I said before, this whole thing seems to revolve around design choices. Apple's chosen to abstract and more tightly restrict threads, which makes sense for a workstation-type OS. And yes, Apple may be marketing OS X as the be-all and end-all of server performance, but that's not what I'm really interested in discussing. We've known for a while that OS X Server isn't a good choice for big iron.

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.

Absolutely. They're perfectly legitimate comparisons, but they certainly don't tell the whole story.

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.

Re:Where are the workstation tests?

[HuguesT]

I disagree,

Ordinary desktop usage shows hundreds of theads active. It doesn't take long at a MacOS/X desktop to find out that the scheduler doesn't do a very good job (this is on 10.3, apparently 10.4 is worse).

Whereas at any Linux desktop if you do nothing the CPU meter shows almost exactly 0, even a reasonably busy desktop with lots and lots and apps and windows open ; on a similar OS/X desktop even though none of the apps are doing anything, the CPU meter typically hover at about 15%. This seems to be pure scheduler overhead.

On MacOS/X it is typically impossible for any app to take anywhere near 100% CPU. There are specialized (shareware) apps that make it easier to manually put all the apps you are not using right now *to sleep* so that a given front app can take more of the CPU. The typical example is iTunes when it converts a CD to mp3.

iTunes never gets more than 80% CPU even though it is working full tilt. With the aforementioned shareware (called Cunning Fox or something like that) iTune can work at near 100%. In effect the difference is much more impressive. iTunes becomes suddendly about 40-50% faster at converting the tracks.

To me this is clearly evidence of a badly broken scheduler.

Overall I find OS/X not very well optimized for desktop usage. Sure the GUI is pretty and functionnal, but there is just too much wasted overhead and it does show. MacOS also requires VASTS amounts of memory.

I almost never swap on my 1GB RAM Linux desktop. My 768MB OS/X machine starts swapping when I read mail in addition to browsing the web. This is unacceptable. After about a week of usage I have to reboot so much it thrashes around everytime I switch apps.

Apple still has a lot of work to do. Can't it port Aqua to pure FreeBSD?

Re:Where are the workstation tests?

[Anonymous Coward]

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.

It is a sad state of performance loss, as Apple has basically made a kludge to avoid the performance problems from its Monolithic kernel.

It amazes me that no one ever notices or pays attention to a different kernel design, that avoids both the Linux kernel thread level and the OSX monolithic kernel.

What is this magical kernel technology. It is called the NT Kernel, and was designed by the best *nix and OS theorists at the time, whether you hate Microsoft or not.

Culter's team was able to create a kernel technology that offered a high level of performance but yet without having the pitfalls that most non-monolithic kernels face by having to deal with the high level of thread calls.

NT is a fairly unique Client/Server kernel design, meaning that it allows OSes to run on top of the NT kernel design (reducing traffic to the NT kernel) and yet not having a monolithic or semi-monolithic kernel.

That is why the Win32 OS Subsystem, has its own OS Kernel, and why NT can run the Win32 OS Subsystem along side the Unix OS subsystem. All without the performance pitfalls that plague OSX, and without the massive kernel traffic that plagues Linux.

Re:Where are the workstation tests?

[Anonymous Coward]

I love this comment. Rock on.

Re:Where are the workstation tests?

[Guy Harris]

OS X has also migrated away from userthreads

OS X never had userthreads. The article corrects that misconception from the previous article:

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. It was one of the reasons why MySQL ran badly on FreeBSD 4.x and older. In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace.

Apple Tech Note from which the picture that was in the article at this point was taken

However, this is not the case of Mac OS X. Pthreads, available to the programmer, map directly to a Mach thread, and thread handling is the very heart of the Mach kernel inside the OS X kernel.

Re:Where are the workstation tests?

[Guy Harris]

In Linux, everything is a kernel thread.

As opposed to OS X, where every thread has a kernel thread:

One useful way to think about Mac OS X's various threading APIs is to arrange them in an layered hierarchy. For example, each MP task is layered on top of a pthread, and each pthread is layered on top of a Mach thread.

(which is presumably what you meant by "everything is a kernel thread").

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.

As opposed to Linux's design choice, where user-mode code is in userland and kernel-mode code is in the kernel, and user-mode code can't run amok in the kernel.

Re:Where are the workstation tests?

[ylon]

Well, there does appear to be a problem when, used as a workstation and having greater than 2 or 2.5 GB RAM, that something bad happens with simultaneous threads... Hope it is fixed soon.

Re:Where are the workstation tests?

[Guy Harris]

on a similar OS/X desktop even though none of the apps are doing anything, the CPU meter typically hover at about 15%. This seems to be pure scheduler overhead.

Have you run top or Activity Monitor on an (otherwise) idle OS X desktop? I'm running it right now, and the main consumers of CPU time are Safari and, err, umm, top and Activity Monitor. (WindowServer pops up on occasion to draw the text and pretty pictures for Activity Monitor and for Terminal on behalf of top, and Terminal's showing up as a middleman between top and the window system. pmTool, kernel_task, and coreservicesd also consume a little bit of time.)

So, at least on my desktop, if you subtract out top (and Terminal) and Activity Monitor, as all of them would be idle if I weren't measuring (and a lot of WindowServer wouldn't be there, either), you have Safari, which is probably drawing a bunch of stupid animated-GIF ads, and some system processes.

I.e., perhaps those apps were doing something, even if it's not something useful (I certainly wouldn't, for example, describe the 50 babies wiggling around on those stupid popup mortgage ads as "useful").

Re:Where are the workstation tests?

[Guy Harris]

NT is a fairly unique Client/Server kernel design, meaning that it allows OSes to run on top of the NT kernel design (reducing traffic to the NT kernel)

...by not actually sending messages to the NT kernel for a lot of APIs. Instead, many Win32 APIs call user-land stub routines that trap directly to the kernel, with the kernel calling routines to handle those traps.

This is, of course, completely different from the way Linux and OS X work. In those OSes, many UNIX APIs are implemented as user-land stubs that trap directly to the kernel, with the kernel calling routines to handle those traps.

Re:Where are the workstation tests?

[HuguesT]

Try opening lots of quiet applications. I have Mail, Finder, Firefox, Terminal, Emacs, Activity monitor, Preview and Nvu.

None of these apps are doing anything special. Flash, animated GIFs and PNGs and Java are disabled in Firefox, yet my average activity level is 15-20% with peaks at around 50%. Firefox is indeed the most active application because I'm typing in one of its tabs, but that's all.

Comparable activity under Linux with a comparable CPU is damn near absolutely zero. This is on an iBook. I tested this with Ubuntu.

This iBook heats up and the fan starts when I browse "too much". To get the same effect under Linux I have to be recompiling the kernel or something to the same effect.

Another effect is that in the situation described above (many apps open) no app can get anywhere near 100% CPU when they need it. 80% is the max, or thereabouts. Of course if you close all the idle apps then of course you can but this is not a good thing.

Conclusion: the OS/X scheduler could work better. I'd like it as well if I had some way to turn down the eye candy. I don't care about transparent windows! Let me use my CPU as I see fit!

Re:Where are the workstation tests?

[Guy Harris]

Try opening lots of quiet applications. I have Mail, Finder, Firefox, Terminal, Emacs, Activity monitor, Preview and Nvu.

None of these apps are doing anything special. Flash, animated GIFs and PNGs and Java are disabled in Firefox, yet my average activity level is 15-20%

So what is Activity Monitor showing as consuming that CPU time? Does the CPU time consumed by those processes add up to the activity level you're seeing?

If so, that's not the scheduler's fault; a scheduler that doesn't give some process or processes any CPU time even though those processes are runnable and there's idle time definitely could work better. :-)

Another effect is that in the situation described above (many apps open) no app can get anywhere near 100% CPU when they need it. 80% is the max, or thereabouts. Of course if you close all the idle apps then of course you can but this is not a good thing.

My definition of "idle", in this context, is "blocked 100% of the time waiting for an event". If all the apps in question (the apps that, if you close them, let your app get 100% of the CPU) are truly idle in that sense, then whatever's wasting the extra 20% of time, whether it be the scheduler or some other part of the system, is at fault.

However, if the apps in question aren't idle in that sense, even if they're supposed to be just sitting there waiting for your input, then I'd say it's the apps that are at fault; how is the scheduler to know that they're just wanking rather than performing useful work?

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.

Re:Real world performance

[ScrewMaster]

I tried for three days to get bluetooth to work on my pc laptop, and never did.

Me either ... and I don't have a Powerbook. Hm.

Re:Real world performance

[GoRK]

Amen! And my pc still wont suspend or hibernate with bluetooth enabled!??! And you can't download an updated bluetooth driver?!?

The one advantage of bluetooth on windows albeit with the severely bloated widcomm stack is that it offers a boatload of profiles and services compared to the mac side. On windows you can use the computer as a bluetooth headset or DUN target.. Try as I might I have never figured out how to use my powerbook as a speakerphone, which would be a killer app for me.

Re:Real world performance

[TheNetAvenger]

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 that's scary... Should they even let you post here if this is such a daunting task.

Here let me help:
1) Turn on Bluetooth Device (or insert BlueTooth Dongle)
2) Insert Driver CD.
3) Press the Next Button
4) Connect to your Bluetooth device.

I have cell phones, mice, headsets, and scores of devices using bluetooth. Built in Bluetooth, to Bluetooth Dongles on almost every computer I own.

Never once was it a problem to install or make any of them work AUTOMATICALLY, with only a click or to when setting up the initial device discovery and profile that I wanted to use for the device. (Something that is considerably more robust that Apple's Bluetooth offerings.)

I love these stories, Wow Apple is so much easier, cause I tried forever to get it to work with la la la... These people are either really scary, or making crap up.

Secondly, this would be more a Bluetooth issue, as the driver and the stacks come directly from the Bluetooth development groups, not from Microsoft, and EVEN not from Apple.

(WTF. Do you like admitting you aren't bright enough to turn on a light too?)

MySQL and other animals...

[MosesJones]

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

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.

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.

Re:MySQL and other animals...

[WinterSolstice]

At my company they are largely graphics people, but our web admins are starting to go to them, and I (a lowly sysadm) and beginning to bring my personal one in to supplement my Solaris system.

Macs are branching out all over.

-WS

Re:MySQL and other animals...

[jsebrech]

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

Arstechnica covered this. As I understand it, it's because the windowing system runs on the graphics hardware instead of on the CPU, allowing smooth window operations even when the CPU is heavily loaded.

Re:MySQL and other animals...

[Anonymous Coward]

I have used OS X extensively and OS X Photoshop certainly doesn't perform well under OS X either; it's much faster on Windows/x86 on comparable hardware. In most cases, it's much slower.

Re:MySQL and other animals...

[SewersOfRivendell]

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.

This article certainly doesn't prove that, or anything, really. I don't know what the guy's thinking. He dismissed the fsync issue without looking into it at all, and without bothering to configure MySQL to work around it even just to see if he could possibly be wrong. No, it has to vindicate his pet theory: there must be something wrong with Mac OS X's threading architecture. He still can't be bothered to compare apples to apples.

It would be really useful to have real apples-to-apples benchmarks on performance and scalability on the same machine with different OSes. But this article is totally unprofessional and misleading, at best. Is this the usual standard at AnandTech?

Re:MySQL and other animals...

[Anonymous Coward]

>> Macs are used throughout the company by many people for different reasons.

Your company must have kick-a** SQL servers. LOL :)

Yesterday's news

[mc900ftjesus]

I read this article yesterday when it was posted. For a news summary site, ./ isn't very quick.

Also, what's with the barrage of Apple/Intel/iPod/DRM/HDDVD/*AA/Lawsuit articles? These were interesting for the first few months. 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."

There, I covered the last 6 months of /. articles.

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

[jcr]

I think you could also speak for most database users, and say that it doesn't matter how many MySQL transactions you do, if you can't rely on data integrity.

Until and unless MySQL is fixed, this comparison is meaningless.

-jcr

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

[Otter]

That's all nice and all for you, but Apple does sell these things the call XServe's that are supposed to be "servers".

That'd be fine if they were:

1) Discussing OS X as a server

2) Testing an XServe, and not a desktop model.

Of course then there's still the question of using MySQL as a proxy for "server" but, whatever. The point is that the reviewer repeatedly treats MySQL performance as an all-encompassing metric for MacOS itself.

Re:Really...

[Anonymous Coward]

He used MySQL as a test application (no problem there, it's a common application people would want to run on a server) to determine possible bottlenecks and came up with some data and possible conclusions, none of which are off base. The conclusion was that the multithreadedness of an application seems to have an adverse effect on its performance in OSX, and this is NOT a hardware issue. Informative.

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.

Re:Really...

[tgibbs]

Testing an XServe, and not a desktop model.

Plenty of people run OS X Server on Apple's tower computers (we do, in fact). These are general-purpose computers, not "desktop" models like the iMac. OS X Server predates XServe, and is marketed as compatible with any Mac system.

Re:Really...

[Anonymous Coward]

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.

Sorry, but that perfectly describes the main reasons that most mac users gave for buying one! "Look how pretty the case is!" and "Look how fast it does some particular photoshop plugin!" were two of the main arguments I have been hearing for *years* from the damn mac people.

It's sad for the mac people to do that kind of thing, but at least anand has a *very* real reason for a benchmark like this. It helps that it is also extremely relevant to many other sites. One of apples great 'features' is the ability to run everyone else's free software, and this is one of the biggies.

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

[AKAImBatman]

Gah, I knew I should have checked that:

s/used the BSD 4.3 and 4.4 kernels/used the BSD 4.2 and 4.3 kernels/g

The earlier versions of Mach required a Unix license to experiment with, while the later versions were completely free thanks to the 4.3 version being completely free from USL source.

More info on the Mach kernel (and why it was actually not a good implementation) here. Note that the OS X XNU kernel has been changed to eliminate the most problematic performance issues.

Re:Hrmmm

[Midnight Thunder]

Just wanted to chime in with these two links, describing the architecture:

  - Architecture of MacOS X
  - XNU: The Kernel

and then some more from Apple on Darwin:

  - Darwin Documentation

Re:Hrmmm

[feijai]

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. ... these frameworks are written in ObjectiveC, which means fun times for driver writers.

I'm pretty sure that's incorrect. NeXT, er, Apple has largely relegated Obj-C to the AppKit and FoundationKit, which are in the upper eschelons of the system, approximately in the equivalent position as X and the widget sets in Linux. Indeed, under the FoundationKit, stuff is mostly in C and C++. As to drivers, maybe things have changed a lot, but I thought that Apple had gone the same way that NeXT had before: its DriverKit had an Obj-C front-end but was really mostly written in C++ (as were the drivers).

Re:Hrmmm

[AKAImBatman]

What I know for sure is that Apple has a bridge in their compiler that allows for Java, C, and C++ to all link against ObjC. AFAI knew, all the kits were ObjectiveC code. Of course, I could be wrong about that part (wouldn't be the first time). :-)

Either way, Apple certainly goes out of their way to bring an ObjC "flavor" to their driver kits. Oh, and their documentation for the IOKit is *terrible*. At least in the Jaguar documentation I have on my laptop. :-)

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

[Anonymous Coward]

Dude, you should check your facts yet again.

4.3 was encumbered. The first BSD with no USL source was 4.4-Lite.

Re:Hrmmm

[AKAImBatman]

If you want to get *really* technical, we're both wrong. The BSD kernel in Mach 2.5 (and in XNU) is neither above nor below the Mach portion. Rather, it's one kernel with some services handled by Mach and some by BSD. In the original design (according to the sources I've read) pretty much the entire BSD 4.2 kernel was linked in with the Mach IPC structuring. The result was that it was an even bigger monolithic kernel than before, but with support for micro-kernel extensions. Mach also added a more powerful scheduling system utilizing threads as well as processes.

20 years later, you can see practically the exact same structure in XNU.

The reason why I say that Mach is a super-kernel is that it was theoretically portable to other kernel structures. The end goal was to kick the regular kernel services upstairs, but until 3.0, it just sort of attached directly to whatever kernel it was linked with.

What isn't clear to me is, did NeXT or Apple ever upgrade to the 3.0 Mach kernel then overhaul it, or did they stick with the higher performance 2.5 series and hedge their monolithic bets? :-)

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.

Re:Hrmmm

[joib]

AFAIK OSX uses Mach 2.5.

And that was the biggest mistake they made with OSX. I mean, by the early 1990:s it was clear that Mach performance sucks. That doesn't mean that microkernels as such are bad, see e.g. L4. Just that Mach sucks. Too bad Avi T. still is in denial. ;-)

A traditional monolithic kernel might be "old-fashioned", but they have been proved to work.

Re:Hrmmm

[mclaincausey]

I believe OS X drivers are normally written in Embedded C++, assuming they are IOKit...

Re:Hrmmm

[drunkenbatman]

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.

This is insanity, and not anywhere close to true. In fact it's almost the reverse, with Mach being more of a background technology. There are very few app that need to modified to keep Mach-specific things in minds, for the most part the system appears as a BSD variant with a different executable format. Rip out the BSD in OS X, and nothing can do anything.

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

The frameworks are primarily about GUI apps, which is where you'll find Obj-C. Obj-C isn't found at the lower levels you're talking about. I believe IOKit had Obj-C interfaces available in the NeXT Days, but its a restricted subset of C++ for drivers in OS X.

Re:Hrmmm

[mclaincausey]

True, but more precisely, IOKit drivers are written in Embedded C++

Re:Hrmmm

[mclaincausey]

No, they did not use 2.5. 2.5 is a huge kernel because it contains 4.3BSD as well as CMU Mach code--Mach was originally developed inside of BSD. As Mach became more of a microkernel, they threw more and more kernel functionality outside of the kernel. The idea is that the same services may be provided, but they use the Mach primitives to accomplish those tasks: it's somewhat reminiscent in this way as the RISC concept: fewer, simpler, low level, primitive calls can be pieced together to form more complexity. Version 3 fully deposited all Unix functionality outside of the kernel. I'd say OS X either uses version 3.x or 4.x (which I think was actually developed at Utah), and then a modified version at that. There would simply be no point in using 2.5. Yes, the performance is better, but only because it isn't a microkernel at all--you only use Mach if you want a microkernel. If you were going to use 2.5, you would be better off using FreeBSD all the way.

You can almost look at Mach as a virtual machine layer that alllows you to deploy operating systems on top of it. FreeBSD is on top of Mach, though for some things, the FreeBSD layer reaches the hardware directly.

Re:Hrmmm

[mclaincausey]

You're both wrong, or at least overstating your cases. FreeBSD provides, for the most part, Unix user space functionality. Almost all of the essential functionality that must exist in an operating system is provided by Mach. This includes memory management, IPC, real-time support, VM, and other crucial functionality. Saying that either part "doesn't do a lot" is untrue. Mach is largely the guts of the system, right above the hardware, and FreeBSD is Unix space, sitting on top of Mach, providing an interface to it, managing processes, etc. If by "background technology" you mean that the user is largely unaware of Mach, I'll agree. But Mach handles the most essential primitives of the OS--almost everything you do in OS X has to go through Mach at some point.

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:Interesting, but let's sum it up:

[Anonymous Coward]

"How many people try to run enormous traffic sites on OSX Server?"

Let me think now....

Apple? ahref=http://toolbar.netcraft.com/site_report?url= http://apple.comrel=url2html-18051http://toolbar.n etcraft.com/site_report?url=http://apple.com>

Re:Interesting, but let's sum it up:

[alienfluid]

How many people try to run enormous traffic sites on OSX Server? Nobody?

Umm .. how about apple.com?

Re:Interesting, but let's sum it up:

[LurkerXXX]

Because:

1) You can't get OSX on top end x86 hardware to test.

and

2) They do talk about kernel locking issues which should be the same wheather the OS is running on PowerPC or x86 hardware.

Re:Interesting, but let's sum it up:

[oscarmv]

But I seriously doubt they use MySQL as a database back end. Oracle would be a safer bet.

Re:Interesting, but let's sum it up:

[justsomebody]

How many people try to run enormous traffic sites on OSX Server?

Almost all (poor stupid people) that bought XServe. Believing stupid commercials saying that it is the fastest combination of hardware and software.

It seemed that the authors were trying to make a point about the G5 vs. X86, and why Apple switched

YDL is faster than Intel in some cases, and there's a drawback diff for YDL tests. YDL was running on 2.5GHz dual, while Darwin was running on 2.7GHz dual.
Tests were won by Opteron and dual 2.5GHz G5 almost outperformed dual Xeons? Where did you get this idea about reasoning Intel switch?

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

You missed it. (on the second page)
Scope and Focus
Again, we are focusing on workstation and server applications, especially the open source ones (MySQL, Apache) as Apple is touting heavily the importance of their move to an "open source foundation".
The 64 bit Apple Machines were running OS X Server 10.4.1 (Tiger) and Yellow Dog 4.0 Linux version 2.6.10-1.ydl.1g5-smp. The reason we chose Yellow dog is that Terrasoft, the company behind this Linux version, optimises only for the G5. So, Yellow dog is by far the most PowerPC optimized Linux distribution out there.

OK, Linux is faster. So? I don't get it.

What is here not to get??? Linux is faster. Hell, even Windows are much much closer to Linux than OSX. Look at the same tests between Win2003Srv and Linux. Meaning on the same hardware Apple doesn't stand a chance against Windows in performance.

Re:Interesting, but let's sum it up:

[MrResistor]

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.

Why is Apple switching to Intel? Because they claim IBM's design failures are what's holding them back performance-wise.

The whole point of comparing OSXvs. YDL on G5s, to me, is to test the validity of Apple's arguement. And guess what? Apple's arguement seems to fail.

What the test shows is that the G5 is capable of performing on par with comparable x86 offerings, and that, in fact, it is OSX that is holding the G5 back, not the other way around as Apple would like us to believe.

So, since the problem is actually OSX, and not the G5, exactly what opportunities does switching to x86 bring? Another opportunity to confirm that Apple sucks at systems programming?

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

[Courageous]

...Why intel?...

One word: laptops.

C//

No DSP testing though?

[Anonymous Coward]

Of course if you actually want to see the strengths of the you need to be running code written to use altivec/ve, since that's one of the reasons you've seen xserves cropping up in the scientific community in the first place and why I think you're going in many cases to see IBM Cell workstations start to crop up in their place rather than x86 xserves. SSE is inadequate or at least incredibly messy for many things.

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

[SuperBanana]

I would have rpefered Apple going with AMD opteron's or contracting one of their other beefy 64 bit chips. Why intel?

AMD has, and always will be, something of an ugly duckling in the industry. Intel is the giant, the name every investor recognizes. Also, I seriously doubt AMD gave Apple a better offer pricing-wise than Intel.

I agree, it's disappointing, but among other things, there's nothing to guarantee that Apple won't, at some point, switch to/also offer AMD.

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

[jedidiah]

I would like you to tell us all just what sort of rocket science is required for maintaining such a machine if it is a Linux box (as opposed to OSX).

Re:Software

[ACORN_USER]

...It's great to use as a school website server, and as a workstation at the same time....

So.. you're running the school's webserver off your workstation? Ahem.

You're one of those sys. admins from that school in Kuztown, PA, aren't you?

Re:Software

[jacklexbox]

Its not rocket science, but for the technically inadept, and the Apple only fans at my school. I was saying OS X works just fine for us, and speed isn't that big a deal in this case.

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.

Re:Software

[ACORN_USER]

That's well and good, but you're still logging into your schools web-server and running desktop apps. Be it dreamweaver or an xterm, my general attitude is that you have servers for daemons and you have desktops for mortals. One of the practical reasons for which I'd never allow this is that I don't want to put a web monkey using dreamweaver in front of my box with physical access to consoles and a big neon-blue 'power' button. That's alright at home, but not with a 'school's' webserver. Especially if your users are naturally curious kids.

Further, the web-monkey's user experience would probably be completely ruined by latency once the school's web site got /. 'ed.

Further it would totally ruin the slash-dotters experience once mr. user decided to go off and try using something like croquet ( well it slowed my mac down when I tried it; )

Not A Good Benchmark

[RickHunter]

MySQL? That's pretty much all you need to see to know that these guys don't know what they're doing.

Re:Not A Good Benchmark

[Anonymous Coward]

So agreed. At least they aren't using a PHP benchmark, although I'm sure one is in the works.

Re:Not A Good Benchmark

[Anonymous Coward]

There's always an anti-MySQL snob making dismissing remarks with nothing to back it up. Sure, they could go and propose a better benchmark, but that would open themselves up to the very same attacks that they think makes them sound smarter.

Re:Not A Good Benchmark

[prockcore]

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

Re:Not A Good Benchmark

[Lars T.]

Ahh, but they didn't test OSX Server, and we don't know whether that ships with a version of MySQL that is fixed.

Yes But...

[gurutc]

They didn't have performance results for which platform ran Solitaire better.

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?

Re:Non-Apple G5 hardware

[Anonymous Coward]

Mercury Systems and terraSoft Solutions ( YDL ) plan a Xserve-like machine. No price yet.
http://www.linuxjournal.com/article/8541
http://www.terrasoftsolutions.com/products/mercury /xr9.shtml

Re:Non-Apple G5 hardware

[Wesley Felter]

A non-Apple 970 system would be twice the price of a G5. Do you still want one?

iSQL

[RUFFyamahaRYDER]

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

Re:iSQL

[Blimey85]

One of Apples lawyers will be at your door any minute now thanks to you divulging their latest trade secret. That was the big announcement Steve had lined up for his next big iSpeach. Now you've gone and ruined the surprise!!!

Re:iSQL

[RUFFyamahaRYDER]

iSorry... =(

Re:iSQL

[sharkey]

Will iSQL be pronounced as "Eye-squeal", and who will be in the commercials?

Re:iSQL

[BlackSnake112]

Isql has been used for a long time in MS SQL products. Like since SQL 6.0. IS Steve going to buy it off of Bill?

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

Um.

[mcc]

but unless I missed it, there isn't any discussion of OSX Server on X86

I assume this is because you cannot legally get OSX Server on X86 right now, nor is it even finished, making it simultaneously impossible and silly to include it in a series of performance testing articles?

Re:Um.

[hexix]

No, but you could run YDL on both a G5 and a X86 processor and perform benchmarks.

I agree with the grand parent, I expected a nice comparison of G5 to X86 by using the same OS and applications on each. Obviously this wouldn't be a conclusive experiment as there's always optimizations which usually favor the more popular X86 platform, but still, it would be interesting.

Re:Um.

[timeOday]

I agree with the grand parent, I expected a nice comparison of G5 to X86 by using the same OS and applications on each.

Why benchmark the Mac G5 now? Its execution date has been set, and the server will be the first place it disappears.

The choice going into the future is which OS to run on X86.

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:priorities

[jo42]

And I can deploy two or three Intel/AMD 1U server boxes for every single XServer as far as price goes.

Re:priorities

[Anonymous Coward]

As a windows user I have to agree with you on that...while many of those things do apply to MS and Windows, OS X is definitely not the panacea some make it out to be...

Re:priorities

[Anonymous Coward]

Since Windows sucks on Servers AND Desktops,
having a MacOS X frontend and a Linux backend seems like a win-win situation to me

Re:priorities

[delire]

Just like linux sucks on desktops and rocks on servers, Mac OS X sucks on servers and rocks on desktop

Well founded assertion there, and so rigorously argued. I especially like that part where you say:

Just like linux sucks on desktops and rocks on servers, Mac OS X sucks on servers and rocks on desktop

You, yes you could be the voice of change for millions of Linux desktop users. Users that choose sub-standard, agonising desktop conditions purely out of stubbornness, political revelry and pride. As you so eloquently conclude, it is time we shrug off these false convictions and confess the relative benefits of each platform; so that with clarity of judgement we can be make informed response-able decisions, choosing the best tool for the job:

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

Safe to say none of these users (myself included of course) have ever tried OSX else surely they would have switched already. We need to get your message out there.

I'm working on the t-shirt. You just keep on your toes and jot down anything that comes into your head. You never know, it could be truly Insightful.

Re:priorities

[diegocgteleline.es]

Well founded assertion there, and so rigorously argued

It is indeed.

The fact is, linux sucks on desktops (and I'm a linux desktop user so stop remembering my why I chose it despite of its suckage) and this article proved that Mac OS X sucks on servers.

It's so difficult to understand? There's nothing strange about it

Re:priorities

[Anonymous Coward]

so stop remembering my why I chose it

You're typing in English, but it appears you're thinking in Spanish.

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

[forkazoo]

I would have rpefered Apple going with AMD opteron's or contracting one of their other beefy 64 bit chips. Why intel?

If Apple were releasing a server today, it would probably make sense to have Opteron in it. We don't know what Apple's first Intel based Mac will be, and it sure as hell isn't being released today. The Pentium-M derivative that will apparently run the first Intel Macs will, by all accounts, be 64 bit. It will also be dual core. What's more, it should be entirely competitive with what AMD has out at the time, and do it at very few watts.

Apple isn't stupid. It's not like they did this as some random guesswork based plan. They carefully considered the roadmaps that they could see. They looked at Cell. They looked at a lot of things. Intel simply had the best product in the time frame they were looking at.

I'm not argiung that AMD doesn't have superior chips to Intel right now. I have an Athlon64 in my own system, and I love it. I have been eyeing a dual-core/dual proc (quad core total) Opteron workstation as my next system if I can afford it. But, this time next year, it could well be that I am looking at Intel much more closely...

Re:Blasphemy!

[Anonymous Coward]

Shouldn't you sig be better written as:

do() || do_not(); assert(! try());

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.

Re:Wait, WTF?

[Anonymous Coward]

And where do you think those UNIX services come from?
Because the answer is, FreeBSD.

Actually, no. FreeBSD is used as a reference for *new* BSD code. The majority of the BSD code was carried over from NextSTEP, and was written *before* FreeBSD even existed.

Re:Wait, WTF?

[merdark]

Mach is indeed a kernel by itself. It is a microkernel. The definition of a kernel is NOT to provide all UNIX services.

It's true that the freebsd services run in kernel space though. Also as I understand it, the services are not exclusivly from FreeBSD anyways. They were originally from NetBSD I think, then later had most/some of the NetBSD mixed or replaced with FreeBSD code. So it truly is niether FreeBSD, nor NetBSD. It is Mach with some BSD based kernel services running in kernel space.

NT uses the same model by the way. It it a microkernel with other services running in kernel space.

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.

Re:Why Apple Didn't Choose AMD

[NovaX]

Also remember that Apple's brand includes the "quality" moniker, which is also associated with Intel and IBM. This is not so deep rooted in buyer's mind with AMD, who was seen as the low-cost supplier. There were numerous QA problems with AMD-based systems even with the early Athlons (often because of buggy chipsets, namely from VIA). Apple is a company that lives off its brand, so potentially deteriorating its value is another just reason to choose Intel.

Re:Why Apple Didn't Choose AMD

[arkanes]

Because Intel famously ships only quality, well tested chips, like the first run P4s and the Itanium, right? You're 100% correct about the chatacterization of Intel (Intel Inside splashed up everywhere, and only low cost/third party machines with AMD chips, because all the big OEMs have exclusive Intel contracts....), even though it's wrong.

Re:Why Apple Didn't Choose AMD

[Anonymous Coward]

Apple didn't choose AMD for a couple big reason. One of them was given by Steve Jobs

At this point, given that Steve Jobs has maintained for years that the PowerPC chip was more powerful than the Intel offering, and given that now he claims a single Intel chip outperforms a dual G5, without mentioning that the test was running a single-threaded application, I don't believe anything any more that Steve Jobs or Apple say.

Steve Jobs just has too big an ego to be reliable at all.

Re:Why Apple Didn't Choose AMD

[Anonymous Coward]

Okay, bets are on.

2/1 The parent gets modded insightful
18/1 The parent gets correctly modded as redundant/troll

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

[Anonymous Coward]

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.

Potential

[bloke1987]

This article seems to be suggesting the potential of the architecture as much as anything else. It would appear that the IBM G5 processors pack the punch to deleiver a serious kick, but are let down by the software and memory issues. Perhaps it is time for apple to go back to its rebellious roots and do something new and radical in the software front instead of just the hardware. Why are they transfering to intel chips and making it open source when open source on the G5's could prove a strong rival? Dont bow down to the Micro$oft empire!

Re:Potential

[Anonymous Coward]

They're switching to Intel chips because IBM couldn't or wouldn't produce 3GHz G5 chips in the time they committed to, and couldn't or wouldn't produce laptop G5 chips at all. Given that the common misperception is that MHz and GHz are the only thing that matters, a 1.5GHz Powerbook compared to a 3.2GHz Dell laptop looks like it is only half as fast.

If you want to use the G5 architecture, you still can. IBM's not going anywhere. Apple just found out that it couldn't really compete against Windows with its G5s, and it didn't like having its laptops run at half the speed of its desktops *and* with older-generation chips.

Finally, consider what Apple is doing in the software space -- creating an OS that works reliably without crashing, that has a strong focus on usability and a strong focus on security. Compared to the Linux and Windows offerings, those *are* rebellious, new, and radical things.

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:But there's so much more!

[StupdPeople]

Your forgot: - "Some government switched from Windows to Linux, and back to Windows!"

Re:But there's so much more!

[Anonymous Coward]

You forgot "Breasts!"

Re:But there's so much more!

[Anonymous Coward]

"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"
I would not call an advance the can make people crap their pants neither irrelevant nor impractical.

Re:But there's so much more!

[amliebsch]

You forgot the entire "Games" section:

"An article on 1up.com says: ..."

Re:But there's so much more!

[holden caufield]

You also forgot two more:

"The MPAA (or Lucas) sucks...but check out this great movie being released!!!"

and everyone's favorite: "dupes".

Re:But there's so much more!

[Mr. Underbridge]

You're right, I forgot Star * movies. And you forgot Buffy.

Re:But there's so much more!

[Anonymous Coward]

If you put the words "nanotech" and "transistor" on the same page, people here think they're getting 1000 THz Pentiums in 3 years.

Re:But there's so much more!

[mc900ftjesus]

And:

Blogcasting your iPodsphere in the bloggulating blogtations of podcasted LOLing with a blogged DRM under the GPL with Linux running Vista running OS X installed by Linus on an iPod that runs in Intel that blogs on its own.

Re:But there's so much more!

[Mr. Underbridge]

Sadly, I thought of that one but I started retching as I typed. Some things are just too horrible.

Um, yeah...

[chaboud]

"By the report the G5 processors are just as fast as the fastest x86."

Which is funny, because they took the fastest available G5s and pitted them against the second fastest available single-core Opterons.

I also don't buy the gcc as an equalizer assertion given in the test. They've already shown that gcc doesn't produce apples-to-apples results, and now they've shown that it doesn't produce improving (or even consistent) results in newer versions.

I'm willing to accept that they've produced some real-world tests, but the synthetic ones are a bit of a stretch. Yes, the processors have similar performance envelopes, but saying anything more than that is just creating a conclusion with too little real information.

Re:Um, yeah...

[Lars T.]

They've already shown that gcc doesn't produce apples-to-apples results, and now they've shown that it doesn't produce improving (or even consistent) results in newer versions.

Actually, you don't like the results because they have shown improving results in newer versions - for the G5.

Re:Blasphemy!

[Anonymous Coward]

Hmmm... this would probably be more in line with the quote:

do() || do_not(); assert(try() == null);

Mac Mini

[bahwi]

Any idea when the Mac Mini will hit x86? Everyone else has tried to release a Mac Mini clone at x86 and failed, I want to see if Apple can do it successfully.

Plus I wanna get one.

Re:Mac Mini

[javaxman]

Any idea when the Mac Mini will hit x86? Everyone else has tried to release a Mac Mini clone at x86 and failed, I want to see if Apple can do it successfully. Plus I wanna get one.

I'm really just guessing on this, but when Apple puts out an Intel-based mini, I don't think it'll be using current chips. I think it'll be using one of the newer, recently-announced 64-bit chips. The timeframes for the release of these chips and Apple's switch to intel line up perfectly, and I don't think it's coincidence.

Since these are lower-power chips, I don't think they'll have trouble. Besides, Intel ( and others ) can and do squeeze Pentium M chips into all sorts of small enclosures, it's just that they can't do it cheaply and the PC crowd is less interested in cute designs...

Hey, ain't you a tad off-topic ? At least say you don't care about server performance, since clearly you're only interested in single-user desktop... fork() latencies won't affect you! ( See, look, I'm on-topic! Easy, huh? )

Re:Mac Mini

[Anonymous Coward]

hey, maybe try to hit ALL the articles with this question, not just Apple-related ones, and some kind soul might answer and put you out of your misery? /sarcasm

Looks like /. started accumulating morons a long way back - they're all over the UID range.

LAMP

[itomato]

http://en.wikipedia.org/wiki/LAMP

Mostly because of that. It's not just Anand that uses MySQL primarily. They could use Postgres, but the acronym exists for a reason.

You could have OSXAPP - OS X, Apache, Postgres, [Perl, PHP, Python, $P_Script_Language], but then you'd start wading into WebObjects waters..

Speaking of, where is WebObjects in all of this? Does it factor into the bias? Apple lists the following Database Servers:

        * Microsoft SQL Server 2000 8.00.194 (?!)
        * MySQL 4.1.10a
        * OpenBase 8.0
        * Oracle 10g Enterprise Edition
        * Oracle 9i Enterprise Edition Sybase ASE 12.5

I know it will run on Windows, but still.. What does this mean?! I don't know!

Re:LAMP

[nenolod]

WebObjects, originally being a NeXT product, ran under Windows NT4/IIS with the OPENSTEP Enterprise framework. Therefore, WebObjects has the ability to talk to a MSSQL server.

Re:LAMP

[Anonymous Coward]

OpenStep Enterprise never had anything to do with MSSQL.

Thanks for playing, here's a Consolation Prize.

Re:Blasphemy!

[feijai]

The proper form is of course: (if (nondeterministically-chosen) (do) nil) ;; TRY removed from options

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.

Re:And now a word from...

[aliensporebomb]

I would really love to see Xbench results from a DTK
machine even though it would be running under emulation of some sorts.

I suppose it's not possible to do this without violating NDA, correct?

Re:And now a word from...

[Anonymous Coward]

how can an AC be marked as insightful?? No offense, but if you are some sort of ninja developer with all this great stuff, why no slashdot nic? Can you prove anything you just said?

I am the king of spain! Ford is better than Chevy! I can run faster than you can...
  blah blah blah....

heresay, all of it.

Re:And now a word from...

[mr_gerbik]

Blah blah blah, benchmarks are nice, but here's the real scoop:

Are you joking me? You basically said, "Tested metrics are worthless and my subjective (anonymous coward) opinion is gold."

Hate to break it to you bub, but the real scoop here is your opinion is worthless.

Re:And now a word from...

[fbg111]

This is a great thing for Apple, and their Intel-based machines are going to impress and wow people.

Ah, I knew they had a strategy for obsfucating the fact that their shiny new Intel architecture will also include TPM...

Re:And now a word from...

[earthbound kid]

Talking about the Developer Kits breaks an NDA, so nothing you hear about it is reliable, slashdot nick or not. All signing in would do is give Apple an excuse to subpoena slashdot.

Slow fork is why I don't use OS X

[RAMMS EIN]

Ah, a comparison of fork performance between OS X and Linux. I've always known that fork is horrifically slow on Darwin, and this proves it. Incidentally, this is the main reason I've switched to Linux on my iBook. But there are others: dynamic library vs. framework weirdness, memory-hungry GUI, and the slow and slightly unreliable filesystem (compared to reiserfs).

Re:Slow fork is why I don't use OS X

[Anonymous Coward]

and slightly unreliable filesystem (compared to reiserfs).
 
that must be one shitty filesystem.

Re:Slow fork is why I don't use OS X

[Qbertino]

Slow fork is why I use x86 Linux for server stuff.

HW/SW inconsistency and the mass of problems that come along with it is why I use Apple/Mac OS X for all other stuff.

And even comparing Attention-warning-prototype do-not-touch-or-use-for-mission-critical reiserFS with HFS is being silly.
You might want to pitch HFS against ext3 and have a nice academic discussion over wether HFS overdoeses the journals and triple checksums, but ReiserFS is not even in their league.

Allthoug Reiser does have some very cool ideas it will take another few years before they're solid enough for the real world.

Re:Slow fork is why I don't use OS X

[Anonymous Coward]

Perhaps you are talking about reiser4 - unstable and in test phase. Reiserfs or reiser3 is incredibly stable and incredibly fast. People seem to confuse the 2 a lot. Nonetheless, I would think reiserfs is in the same league as HFS - probably better - but as always, it's debatable.

Re:Slow fork is why I don't use OS X

[whiskey tango foxtro]

What a doof, picking your OS based on fork speed and, perhaps, kernel rebuild times rather than what apps you use to Actually Do Stuff.

So you traded Photoshop for Gimp, vi for Dreamweaver, Rosegarden for Logic, and, I guess, nothing for Final Cut Pro, but by god, your fork times RAWK.

Re:Slow fork is why I don't use OS X

[RAMMS EIN]

``What a doof, picking your OS based on fork speed''

Depending on how you use your system, fork can be a very common operation. It happens to be that way for me. Linux feels a lot snappier, and this is probably due to exactly the issues that the article points out. The difference is enough that working with OS X annoys me, so I ditched it.

As for the apps you speak about; I don't have any of the commercial apps, and free ones often work better on Linux. So that's another good reason to switch.

The way I see it, Apple has an impressive GUI and a good amount of support from hardware and software vendors, but Linux is the better operating system.

Concurrency and scheduler artifacts

[Anonymous Coward]

I've noticed from doing a multi-threaded scalability test on single processor systems for OS X, Linux, and Solaris that you can get different scheduler artifacts affecting performance. For instance, how threads interleave using synchronization can have significant effects on performance. If a thread can repeatly reacquire a lock without sharing it with other waiting threads, it can under some conditions run significantly faster since it's not preempting as much. It all depends and is pretty twitchy. I'd be pretty careful about making any conclusions about this area without tuning the application for the platform it's running on. I can tune a multi-threaded app so it runs faster on OS X and slower on Linux, or vice versa. Running it on one setting won't necessarily prove anything.

not quite

[diegocgteleline.es]

Are you joking?

VFS, the filesystem, the whole TCP/IP layer, the POSIX API, all of that cames from FreeBSD code and that's quite a lot of code.

Yes, mac os x uses openstep's kernel. But then, openstep kernel used freebsd code aswell....

I remember a presentation from apple showing percentages of how much code comes from each variant. BSD code was most of it, with the IOKIT being second and MACH-derived code being the last - less than 10%. Shame that I didn't bookmark it...

Avie Tevanian & the CMU Mach Microkernel

[mosel-saar-ruwer]

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?

Boy, I'd give my left - ah - ear hair maybe? pinkie fingernail clippings? whatever - if Avie Tevanian and/or some of the FreeBSD committee members would get on here and talk about the Carnegie-Mellon/Utah/Whosesoever's microkernel and the FreeBSD threading layer and all the cool stuff that I've always wished I knew more about ever since I cut my teeth on a NeXTstation with Interface Builder and the ObjectiveC compiler.

Stares off into the distance, bats eyelids, and releases big, wistful, teenie-bopper groupie sigh...

Re:Avie Tevanian & the CMU Mach Microkernel

[javaxman]

Boy, I'd give my left - ah - ear hair maybe? pinkie fingernail clippings? whatever - if Avie Tevanian and/or some of the FreeBSD committee members would get on here and talk about the Carnegie-Mellon/Utah/Whosesoever's microkernel and the FreeBSD threading layer and all the cool stuff that I've always wished I knew more about ever since I cut my teeth on a NeXTstation with Interface Builder and the ObjectiveC compiler. Stares off into the distance, bats eyelids, and releases big, wistful, teenie-bopper groupie sigh...

You're not the only one... if I had a good x86 machine to compare to my G5, or wanted to mess with installing YDL on it, I'd be writing a pthread() benchmark right now.

As it is, maybe sometime soon I'll put together a system to run Darwinx86, BSD4.9, BSD5.x and Linux, and write a pthread() benchmark for those. Hopefully someone else will do that test before *I* get around to it, though...

If Apple wants to compete in the x86 server space, though, this sounds like something they'd best be working on...

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

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

Re:well...

[LurkerXXX]

MySQL is know to have a 'real-life' problem running on OS X that Postrgres, Oracle, etc, etc, don't. Why not use a program that doesn't have a huge known bug working on the OS your testing rather than one you know isn't going to work right?

Personally I don't like MySQL, but I'd say their 'study' was hugely flawed if MySQL and Postrgres were known to run flawlessly on it, but they instead chose to benchmark Oracle if Oracle was known to have a huge bug.

Re:Blasphemy!

[jocknerd]

Actually, it isn't slashdotters beliefs that Apple doesn't make poor marketing decisions. It is our belief that Apple doesn't make marketing decisions, period. We don't think they actually have a marketing dept. outside of the one that is used for the iPod.

s/Anadtech/Anandtech/

[Anonymous Coward]

Thanks.

Sybase(TM) probably own the trade mark

[ACORN_USER]

isql is the cli utility for interfacing with Sybase.

That said, I wonder if 'isql' is any more likely to be an existing trade mark than say 'ls' or, for that matter, 'mknod.'

what about the apache and lmbench numbers?

[diegocgteleline.es]

They also run apache and lmbench; I don't think you can say they "insist" on mysql...

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?!??!?!?!

[Chirs]

Okay, so why don't you install yellowdog, write the test, and check it out yourself?

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.

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

[javaxman]

Okay, so why don't you install yellowdog, write the test, and check it out yourself?

Yellow Dog costs money last I checked, and I don't really have the time or inclination to do so, frankly. It's all rather academic to me. The XServe and our OS X desktops are more than fast enough to do the work we do, and the convenience of the systems outweighs the cost-savings of Linux. If I had much, much larger data sets to crunch, or was running a large-volume web server, that might be a different matter... but then, especially if I was cost-concious, I'd probably just use Linux from the get-go, and probably not on PPC.

These guys have yellow dog, have the time, have the resources all set up, and are making a big stink about a fork() or MySQL performance problem which I almost don't care too much about unless it's really a serious thread-level OS bottleneck. They should do their job and identify, with reproducable certainty, the source of the problem. Heck, given that they can get both the Darwin and Linux source, they should be able to point out the actual lines of code that are at the heart of the issue. Now *that* would be interesting. If I had the time, I'd do it... but I don't understand why AnandTech wouldn't.

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

[javaxman]

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.

Oh, to be sure! And yet, I'd not be shocked if OS X did even more than all of that, doing stuff like registering the forked application with higher-level message-passing and even application-layer stuff like Finder and Launch Services, causing who-knows-what kind of delays that aren't seen elsewhere.

It's likely that OS X introduces more code in *both* calls, but it'd be nice to see a test that shows where the real bottleneck is. I'm pretty sure the pthread() issues aren't near as bad as the fork() issues, just drawing on some small experiences porting linux apps... but I've not done the test, and I still don't know why AnandTech wouldn't.

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

[Guy Harris]

And yet, I'd not be shocked if OS X did even more than all of that, doing stuff like registering the forked application with higher-level message-passing and even application-layer stuff like Finder and Launch Services

I'd be shocked if fork() did any of that on OS X. xnu and libsystem know nothing of the Finder or Launch Services or any Carbon/Cocoa/CoreFoundation/etc.-level message passing (although they provide infrastructure that those facilities use); higher-level app framework code handles that stuff.

PowerPC is Supposed to be Better for Servers

[GnuTzu]

The whole PowerPC architecture includes memory management and such that is generally regarded as better at context switching. This is supposed to facilitate better task switching for servers that run many processes.

IBM's UNIX, AIX, is designed exclusively for PowerPC, the design of the memory managment and such reflects this, while Linux memory management is designed for portability. (There are bound to be some tests comparing Linux and AIX on IBM servers out there.) You'd think that the Apple kernel would take advantage of such things. But then, how many server farms out there run Apple-based systems?

So how many process forks did that MySql test create, and would that adequately represent a cross section of real-world environments?

reload

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

[Anonymous Coward]

I think there's a much more important lesson here:

Mac OS X is worse than Linux on several technical grounds that are never seen by normal users. And geeks are *still* switching to Macs in droves.

You're going to have a hard time convincing me that any performance issues in the Linux kernel are at all important. Get the interface right (or right enough), and people will love you -- even people you might expect to care about fork() performance.

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.

Re:OS X lacking

[MECC]

Mac OS X is worse than Linux on several technical grounds that are never seen by normal users.
I think I'm going to install unbuntu on my iMac 800Mhz and directly compare it to OSX 10.4. That part of the article bugged me. They could have easily compared two OSes on the exact same machine and didn't.

Get the interface right (or right enough), and people will love you -- even people you might expect to care about fork() performance.
No argument there, to be sure. I care about thread, fork, signal, and IPC performance, and I have a ThinkPad A22m running Ubuntu 5.04 next to an 800Mhz iMac. I mostly use the iMac.

Still, the ThinkPad seems to do some things snappier that the iMac. And, more importantly, its mouse never locks up. When I went from OSX 10.3 to 10.4, my mouse started the habit if needing to be unplugged and plugged back in frequently. Bought a 'mighty mouse'. Problem persisted.

I'll see if Ubuntu has the same issue. If not, then its definetly Apple's fault, and they'd have no excuse at whatsoever. I'll post results in my /. journal.

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

[logicnazi]

While I agree that the people who write desktop apps are unlikey to start explicitly coding threads into their applications this doesn't mean the apps won't end up being multi-threaded. For instance with the OS X model for graphical applications (core ?) you already create seperate user interface code and core application code and communicate between them with a message passing style model. As CPUs start to emphasize multi-core/multi-thread features I expect the development assistance tools to automatically seperate applications into threads more and more in the future.

Good practice for most desktop apps is to write them in a modular architecture with various pieces communicating in well defined ways. I fully expect in the future many development aids will formalize/assist in this process and automatically break some of these components into seperate threads. In short I simply disagree that having threads always means increased complexity. With the right sort of tools it can even be an organizing principle for a great deal of code.

Also between word processing, graphics, and web browsing you probably have a fair chunk of the desktop application usage all of which either do or would benefit from multiple threads in multi-core enviornments (I think despite what you say photoshop is already multi-threaded or something similar to take advantage of multiple processors). Additionally network based apps are quite well suited to a multiple thread model (seperate the data/network handling part or parts from the core program).

Re:Unlikely ..

[CoughDropAddict]

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.

I hope you don't write desktop applications. At least not ones that I have to use. It's attitudes like this that make the majority of this generation's UIs so clunky.

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.

Right... they never do things like:

• disk i/o
• network i/o
• CPU-intensive tasks like searching a 100k web page for a string

Most desktop application functionality is inherently synchronous too (driven by user interaction), so I think very few applications will benefit from being multi-threaded.

Consider the incremental search feature in Firefox. I mention it because it's sitting in front of me, and is a prime example of why single-threaded GUI programs suck so bad. Every time I type a letter, it searches the whole web page for the one-character-longer string. If I have a large web page loaded, it takes a really long time, and practically stalls the GUI.

Yes I know that searching the whole document for every letter is the very definition of incremental search. But if the program is 50% through searching this huge HTML page, and I type another character, I want it to immediately stop what it's doing and listen to ME! But it doesn't, and instead I spend a few seconds waiting for my super-powered 2005 computer to perform a search I don't even care about.

All because people like you think that threads provide zero benefit.

You might say "but I can check in my text-processing loop to see if the user cancelled the operation!" Sure, as long as you put these pre-emption points in every single place I might want to pre-empt what you're doing. But the proof is in the pudding: apps just don't do this.

If you don't realize how sluggish GUIs are, you never used BeOS, which had the most responsive GUI I've ever used. And that was in 1999. And (coincidance!) it was heavily multithreaded.

Re:Unlikely ..

[BeanThere]

All because people like you think that threads provide zero benefit.

No, don't put words in my mouth, I actually agree with you in this case - Firefox search is definitely one of those cases where putting the search in a thread would be a good idea, and that happens to be one of the things that annoys me in Firefox. Another incredibly annoying case is Windows Explorer which if you click on a network drive that isn't available checks synchronously for it and then you can't do anything for two minutes until it times out - that's just pathetic. I put threads in my apps WHERE IT MAKES SENSE TO DO SO, and where development resource constraints allow.

But I didn't friggin say that threads have zero benefit. Please point out to me where I said that. I said that IN MOST CASES threads provide zero benefit. Consider that 99% of the time users are not busy searching in Firefox - the vast majority of time is just spent by users staring at web pages. I hardly see thousands of threads beings launched, and it certainly doesn't prove the original poster's attempted point that poor threading performance in Mac OS X will become a serious problem on the desktop, because even if Firefox did use one occasional separate thread to search the performance problem would be totally negligible.

The Windows UI is sluggish, sure, but not because it doesn't utilise threads properly, it's because it's a bloated inefficient mess of ActiveX controls.

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

[Lost Found]

Once again, OS X x86 (unless hacked) will not run on a generic IBM PC. You're likely to run into driver issues even if it is hacked.

Also, changing the architecture isn't going to do anything for their performance problems.

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

[PenGun]

DRM DRM DRM DRM ... oh you get the idea ... right?

Old news

[Anonymous Coward]

Moshe Bar did a comparative evaluation of Mac OSX vs. Linux way back in 2002. Look up 'Comparing Apples and Penguins' (need to register w/ CMP to read it, I believe).

Anyway, in the time since then, Apple has apparently done nothing to improve the situation.

If Apple's performance problems are primarily related to their OS, then why switch architectures? I have two guesses:

(1) Apple knows something we don't know about Intel's roadmap.

(2) They know they need a better kernel, they're shopping around for one, and the kernel(s) they are interested in work best on Intel.

Upcoming comparisons from Anand

[Orrin Bloquy]

• Pentium M v. ARM
• PPC v. NSA Beowulf cluster
• Motel 8 clerk v. pouring Squishees at Kwik-E-Mart

Re:Upcoming comparisons from Anand

[Hack Jandy]

Oh oh, don't forget Red Bull v. Coffee. Oh, wait, that would be retarded.

HJ

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

[toddestan]

I don't see why Apple couldn't use Intel for mobile and AMD for desktops. Plenty of PC manufacturers get by just fine making computers using both Intel and AMD processors.

Fab capacity -- or not?

[xenocide2]

You bring up a point highly abused on slashdot, that AMD has less capacity. Capacity isn't difficult to come up with, given a year's lead or two like Apple is giving Intel. But even assuming the launch was next month, what makes you believe that AMD cannot meet Apple's demands? I've seen more than one critic more qualified than 'some random guy on slashdot' describe Apple's needs being a drop in the bucket compared to AMD's existing capacity.

So it's time for Random Slashdot Guys to step it up a notch: how much does AMD produce, how much does Apple need, and how much does Intel produce?

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.

Re:Fab capacity -- or not?

[Kadin2048]

The other thing to consider is how quickly Apple orders those 3.3M units. They're not evenly distributed throughout the year. If they were, then you could easily find some small shop with a 5M unit per year capacity and have lots of room to grow.

That's now how it works though. Apple tends to have pretty spectacular product launches, which are followed with almost zombie-like mass product orders by their userbase. It's totally conceivable that 30% of their yearly orders could come in a very small timespan. (Imagine if they made a big product announcement right before the Christmas buying season.)

AMD may have 36M processor/year capacity, but that might not be enough to tolerate the "rat through the python" effect that a big product launch might generate. And Apple obviously doesn't want to be burned again by partnering with a chip company that can't deliver when Jobs gets up in front of the masses and makes a promise of a product by a date.

Looking at year-total production numbers is fine, but keep in mind that anything to do with retail sales means demand fluctuates, sometimes hugely. You need a lot of production capacity (or a lot of inventory to create safety stocks, which with computers isn't an option due to cost and obsolescence rate) to respond quickly to changes like that.

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

on my g3 ibook

[b17bmbr]

yellowdog 3.01 ran much faster than 10.3. but, for some reason fedora 4 wouldn't run, and i need keynote for my classes. ( I teach.) so, I went back to os x exclusively. but, yeah, linux is faster, at least from my experience.

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.

WebObjects Databases

[kcarlin]

WebObjects uses the Enterprise Objects Framework (EOF) to do object-relational mapping. The Java EOF uses a JDBC adaptor to interact with the database. Apple's supported list of databases are the ones Apple will accept complaints about, many JDBC-capable databases will work. EOF allows for custom enhancements to augment the JDBC-level support for a given DBMS, but any DB with good JDBC support should work with EOF.

As a network app, WebObjects leaves it to the customer to determine the best platform for running application components (including WebObjects), and supports the most popular/lucrative options.

Very likely - Re:Unlikely ..

[Anonymous Coward]

Very likely, especially with the advent of multi-core CPUs, Hyper-Threading and languages/dev systems making it easier and more desireable to do multi-threading.

I don't know about your desktop apps, but the ones I write use numerous threads to keep things live. I am looking at my debug window right now and there are seven threads minimum running in the client app, and over 35 on the server, more when I am actually doing things (especially when talking to the server).

I know people who work at Adobe and other large desktop app development companies - they use threads heavily there too, and the trend is only going to increase as the advantages become compelling and threading is better understood.

Debugging threading issues can be frustrating and time consuming, but in my experience (20+ years worth) most bugs are not due to threading issues - and the advantages outweigh the disadvantages.

Re:Very likely - Re:Unlikely ..

[BeanThere]

most bugs are not due to threading issues

That is certainly true, but on the flip side, threading related bugs are often much much harder to find and fix, because they tend to lead to "random" crashes that aren't predictable caught in a debugger.

I think your perspective is skewed by the fact that you work with complex development applications, and that most of the people you know also do development work. In the real world, 99% of people mainly use e-mail, word processors, spreadsheets and web browsers.

Re:Very likely - Re:Unlikely ..

[Anonymous Coward]

Certainly threading bugs are harder to find and fix, but even with a heavily multi-threaded app, there just is not that much time spent fixing them - which was the original assertion, and what I was replying to. There is a definate benefit to multi-threading and the penalty for the complexity is not experienced that often.

As for a user vs. developer viewpoint, given the issue, I think the latter is more relevant. The user is typically not even going to know that their apps are multi-threaded or not. Indeed, I would guess that original posted doesn't know how many threads the apps he/she uses have. Most apps have at least two or more. The typical Java desktop app starts off with a minimum of seven - several for the UI (Swing has its own thread) and several for other tasks. This is before the developer ever explicitly starts a thread.

The typical user won't see these threads, won't know they are there, unless they are running the app in some kind of development tool or utility that shows them the app.

So, will most apps benefit from multi-core CPUs and multi-threading OSes? You betcha - and this will become increasingly true in the future.

Re:Very likely - Re:Unlikely ..

[Anonymous Coward]

Oh, and BTW - all of your examples, email apps, WP apps, spreadsheets and web browsers, all use multi-threading. I would be hard pressed to find one that didn't. Try an email app, such Outlook or Thunderbird - when they retrieve emails from a server, they also allow the user to read emails and navigate through the app - how do you think that is accomplished? Multi-threading.

How do you think Firefox retrieves HTML from a server in one tab while retrieving another page from another server? Multi-threading.

How do you think a WP does a spell check in the background while the user is entering text? Multi-threading.

How do you think a spreadsheet does a recalculation in the background while the user is entering numbers? Multi-threading.

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

[Cthefuture]

I like my Opteron machine as much as anyone but although AMD makes decent CPUs, the chipsets to use those CPUs suck. Just try to find an Opteron motherboard with the performance and stability of an Intel chipset board. They just don't exist.

I think that is another major reason why Apple went with Intel. I mean Intel's USB and disk controller chipsets are the best in the industry. Intel was also the first to provide PCI Express. Intel chipset based motherboards just whip the crap out of anything you can find for AMD CPUs. nVidia's chipsets are not that bad but still not up to the stability of Intel.

How about something better for less than 2X?

[Anonymous Coward]

An IBM OpenPower 710 blade starts at around $3500 for a single 1.5Ghz 32M POWER5 CPU (the big brother of the PPC 970), 1GB ram and 72GB of 10k SCSI3. It it fully 64 bit, you can add 3 more POWER5 CPU's, up to 32GB of ram and many many gigs of fast SCSI (not el-cheapo SATA) storage, and best of all the machine is specifically designed to run Linux and supported as such.

Although it is not a perfect comparison, for server type tasks this machine will outperform any G5 Mac or Xserve.

IBM does sell a "deskside" form factored version (the 720) for about $5000. Still not twice as much as the top of the line G5 Mac.

So maybe we want Theo to interview Avie.

[mosel-saar-ruwer]

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

I wonder what de Raadt thinks of all this.

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.

[Anonymous Coward]

He was doing standard tests for the things a normal person running a server would be doing. The admin shouldn't have to dick around with "TCP_CORK" or whatever - it should just work. Isn't that the whole selling point of Apple??? Just face the facts man, OS X sucks as a server.

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

[justsomebody]

And after Apple says: "Just works!", there comes a genius blaiming TCP_CORK.

Apache and MySQL come preinstalled in OSX Server. Why would you build it again? I don't do it on Linux either.

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.

[justsomebody]

Yep, and you what has TCP_XXX to do with threads (one of tests too)? TCP_XXX would account for minority here.

Main flaw would be MACH kernel infrastructure and not TCP. Why is microkernel slower than monolithic, I think there enough explanations on the net, so I don't need to explain?

Apple's just another OS vendor, shipping just another set of unusual bugs around, just like the FreeBSD it's built on.

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

Solaris???

Nah, too bad HW support and Suns ability to change their mind over night.

In the other news, Solaris on the right machine is great, but still not reason enough to go to .

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.

[Anonymous Coward]

As anyone who used poll() under heavy load knows, Panther could core dump; Tiger has improved, but it's poll() implementation is still suffering.

Why would you use poll() when something like kqueue() is available and can scale to 10s of thousands of listeners? For all the graphs that have been shown for kqueue()'s performance all of them have had completely linear performance across the board.

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

[Lars T.]

Yep, and you what has TCP_XXX to do with threads (one of tests too)? TCP_XXX would account for minority here.

That's a good one. 'Cause in the test that supposedly tested threads, threads only account for minority.

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

[drunkenbatman]

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

Pretty sure we're just talking about buying a server solution that can't keep up with other solutions if performance matters to you. If you want to use MySQL or some other things, it would appear the Mac isn't what you want to use right now.

However, if you wanted to write your own database server for the Mac, keeping a bunch of Mac-specific things in mind, we might be close to whatever the hell it is you're talking about...

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

[Anonymous Coward]

> in the test that supposedly tested threads,
> threads only account for minority.

A fork is equivalent to thread creation if you don't touch the pages. So their test is valid.

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

[g_lightyear]

OK, no, that's my point - you're missing the point.

If the point of the article is "why mac os x is a poor server install", going around talking about a bunch of untuned applications is a poor way to do it.

Most of us who do high-performance servers aren't interested in whether bog-standard package installs do well, because we don't expect any platform's bog-standard install to be good enough.

Every kernel needs to be tuned for performance. Every kernel, therefore, needs to be tunable. Talking about where Mac OS X *isn't* tunable, therefore, makes for a good way of talking about where the flaws are.

Knowing that it's got major problems with its TCP implementation is another good way of knowing what the true problems will be; knowing about the high cost of context switches, and syscalls, on the platform...

And going into it, that's what I'd expect an article to talk about. Talk about the *real flaws of the OS*.

Running Apachebench? What does that tell me about the OS? All it tells me is that some idiot thinks that an RPM install of Apache is good enough to handle high volume content delivery - and alone, on an off-the-cd install of Redhat, it's not. Or any other platform. If someone else's support-tuned, 'good enough to ensure the vendor doesn't get calls about stability' is good enough to equate to a high-performance environment where high performance is actually *required*, then we're not talking about the same things - and you might as well buy anything.

People who actually need to run high performance systems don't expect good performance out of package installs. They're untuned. You *expect* to build it (for example) for a G5-only optimized system, tuned for your hardware, on the latest compiler you can get your hands on and verify stability of. Not run it on whatever was built to make some support bod's job easy.

So for people intending to *actually make a decision about the OS as a server platform*, this article is actually a sham.

Having said that, I think that Darwin is a pretty crappy kernel for high performance applications. So, as the subject says, there are problems, but these aren't them.

Fix the latency problems across the user/kernel boundary. Reduce dramatically, please, the cost of context switching that makes heavily threaded applications crawl. Do something about the bugs in the TCP implementation, which prevent most applications expecting Linux-like behavior out of the socket system to *not suck* when run on Darwin.

But don't cry about how the package installs aren't good enough - because they're not 'good enough' on anybody's platform when it comes to a high performance delivery system. If they were, people wouldn't run Gentoo.

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.

Missing the big picture

[Anonymous Coward]

...big question marks can be placed on whether or not the switch to Intel CPUs will - from a technical point of view - be such a big step forward as Steve Jobs claims.

Yes, one can easily question if moving from the G5 to Intel will be a performance win. But there are no portable machines with the G5 processor. The iBook and PowerBook lines make up enough of Apple's profits that they can't allow them to plateau. Regardless of what advances IBM has made to the G5, they still have not provided any offering that provides Apple something that can match an Intel Centrino for revising portable products. My guess is that Apple will phase out the G4 before they move on to eliminating any G5 offering.

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

[logicnazi]

Perhaps because of DRM? Apple can't release OS X for x86 until they have some kind of trusted hardware system to prevent the OS from being used on other hardware. Intel probably offered assurances about their trusted computing hardware.

Besides, I expect as before apple boxes will be kinda pricey for their performance thus it doesn't make sense for them to take risks to slice off a bit in processor price. AMD is producing some good chips now but will it still be at the top of the market in several years? Intel is huge and even if AMD keeps the pressure on them their market domination, capital and massive store of chip knowledge and patents guarantees that they will stay competitive for years.

In short it makes sense for apple to cut a deal with the market leader rather than the flashy new competitor.

So, this means nothing...

[Anonymous Coward]

... to 99% of computer users.
 
Yes, it means much more to the /. crowd (Linux, SQL, etc...), as that's why this article was posted here, and that's very nice and all, but... to the normal computer user, it's still an OS X vs. Windoze thang. After switching to Mac I kick myself everyday for not doing it sooner. So when I read this article I realized it had nothing to do with "Apple platform compares, performance-wise, to the x86 PC platform" in normal, real world instances, but with esoteric server BS rather quickly. I moved on realizing the article blurb was a tad misleading.

Who Benefits?

[bmeteor]

so let me see if I get this right... the high level tradeoff is that the user (programmer?) implementing benefits ease of use a distributed system (xGrid?) while the database admin gets lowly performance from mysql. I guess with some really vertical markets that can really take advantage of the vectorization of the g5 combined with distributed systems, OS X makes sense. Who's taking advantage of this benefit?

on the other hand, the end user gets overhead on every single fork() call, meaning making new threads take longer, but the general user doesn't notice this as much since the processes (apps) are much bigger.

Re:Who Benefits?

[Guy Harris]

the high level tradeoff is that the user (programmer?) implementing benefits ease of use a distributed system (xGrid?)

...if any of that whiz-bang cross-machine Mach messaging stuff were supported and used, but it's not.

on the other hand, the end user gets overhead on every single fork() call, meaning making new threads take longer

Only if the threads are UN*X processes rather than pthreads.

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.

Re:Apple's poor choice of using "Asus."

[ArbitraryConstant]

"Unfortuantely you bought when Apple had just switched to Asus for their iBook's logic boards. Their first revs were complete crap."

The flawed computers were sold for more than two years, so I can conclude that Apple either did it knowingly or they don't pay much attention to failure rates. Either is cause for concern, IMO.

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

Other Apple computers have had problems recently, including the PowerBook you propose.

"Apple will replace all iBook logic boards free of charge."

I don't mind the occasional failure, but when the quality is so low that it leads to significant downtime you can bet I have a problem. That 10% I mentioned was over the course of 2 years, so that's a pretty big chunk of time.

There are also major bugs and issues with updates that proper testing would have caught.

Apple has been much better in the past, so I interpret these to be evidence of a declining commitment to quality and I am unwilling to risk another Apple purchase.

I'm also unwilling to even consider them because of the poor specs. minis are too slow, iMacs can't do dual displays and can't be substantially upgraded, and PowerMacs would be great if they had a single-CPU version that cost half as much. If I ignore the reliability problems and the slow CPU in the laptops, there's still the crapper screens (resolution, contrast ratio, etc), the slower hard drives (4200 with 5400 rpm for premium instead of 5400 and 7200 rpm), the shorter battery life, etc. These crappy specs have nothing to do with the CPU so I don't hold out much hope for an improvement post-Intel switch.

I've used OS X, and IMO it's just not worth the associated crap you have to put up with. I'm not basing this solely on my experience, I see ample evidence that I am not alone and that the quality is declining. Unless Apple improves, they're going to lose these switchers just like they lost me.

Re:Apple's poor choice of using "Asus."

[JackAxe]

The flawed computers were sold for more than two years, so I can conclude that Apple either did it knowingly or they don't pay much attention to failure rates. Either is cause for concern, IMO.

Apple replaced the logic-boards no questions asked, and as I already stated, the later G4 iBooks work great. If this were Sony as an example, good luck on getting a replacement. I'm also one of their customers, or "was" I should say, because unlike Apple they don't fix the problems they create.


Other Apple computers have had problems recently, including the PowerBook you propose.

Now I've never heard of this. Both Titanium Powerbooks here have not had that problem and none of my friends with Powerbooks have encountered this either, and I know quite a few since I work with these types of peeps. Like I stated, my Powerbook(s) works great and the past 2.5 years of solid reliable use can attest to that fact.

Apple's a big company, they sell millions of computers, now if they didn't have a hand full of issues here an there, that would make them Gods amongst all hardware companies.


There are also major bugs and issues with updates that proper testing would have caught.

10.4.3 is on the way, so hopefully it will help out with that peeps issues. And I say that peeps issues, since I have not encountered them. Tigers is still a new OS and like any major update, It takes time to iron out all of the bugs. The minor issues I've encountered have mainly been software related. With Tiger I did encounter a few OS related quirks with the first release, which I knew would be present, but after 10.4.1, my reliability shot back up to pretty much where it was with later builds of Panther.

The bugs that peeps described are odd, and if they were "major bugs," I would have encountered them on at least one of my Macs. I work between 12 and 16 hours everyday. I'm self employed, and my business isn't big enough to hire other artists at this time, so I'm doing all of the work. Anyways, I can trust my Macs. A major bug for me, would be a complete system crash every-time I tried to run one of my Apps.

Now if only there were a company that truly had "proper testing." Now be honest, can you name any major update for any system that has been bug free? The answer is no of course.


Apple has been much better in the past, so I interpret these to be evidence of a declining commitment to quality and I am unwilling to risk another Apple purchase

This is no longer true, but it's your choice. I bought my G5 end of 04 and it is the best computer I've used to date. Works like a champ.


I'm also unwilling to even consider them because of the poor specs. minis are too slow, iMacs can't do dual displays and can't be substantially upgraded, and PowerMacs would be great if they had a single-CPU version that cost half as much. If I ignore the reliability problems and the slow CPU in the laptops, there's still the crapper screens (resolution, contrast ratio, etc), the slower hard drives (4200 with 5400 rpm for premium instead of 5400 and 7200 rpm), the shorter battery life, etc. These crappy specs have nothing to do with the CPU so I don't hold out much hope for an improvement post-Intel switch.

Slow depends on what you're using it for. Believe it or not, that Mini can easily womp most PCs when it comes to video encoding. They're great multimedia machines across the board. iMacs are consumer Macintoshes, the computer is the screen, If you need another display, or more upgrade options then buy a tower. The iMac wasn't designed for your needs. Apple did have a single configuration of the G5, but as the cost dropped on the proc, they simply offered a dual configuration in the same price bracket. G5 Towers are also workstations, so they cost more.


The Powerbooks do need a major upgrade, hence Apple is moving to Intel, The G4 hit its roof. The G4 is slow in relation to what is out there now

Re:Apple's poor choice of using "Asus."

[ArbitraryConstant]

"If this were Sony as an example, good luck on getting a replacement. I'm also one of their customers, or "was" I should say, because unlike Apple they don't fix the problems they create."

No one denies that there are crappy PC vendors. The advantage is that there's good ones as well.

"Now I've never heard of this. Both Titanium Powerbooks here have not had that problem and none of my friends with Powerbooks have encountered this either, and I know quite a few since I work with these types of peeps.."

I've seen it on sites like Macslash and Ars Technica, with plenty of people posting to say they've experienced it. That's not a large study, but it's common enough for relatively small sites like that to get people chiming in.

"The bugs that peeps described are odd, and if they were "major bugs," I would have encountered them on at least one of my Macs."

If only all bugs were easy to reproduce.

"A major bug for me, would be a complete system crash every-time I tried to run one of my Apps."

I would consider a "major bug" to be one that prevents me from doing what I need to do. If the guy had to use a Linux machine to finish the post, it prevented him from doing what he needed to do.

"Now if only there were a company that truly had "proper testing." Now be honest, can you name any major update for any system that has been bug free? The answer is no of course."

That's true. But Debian-stable will do many times better than OS X.

"The iMac wasn't designed for your needs. Apple did have a single configuration of the G5, but as the cost dropped on the proc, they simply offered a dual configuration in the same price bracket. G5 Towers are also workstations, so they cost more."

The PowerMacs are priced within reason for a dual machine, but the single-CPU machines weren't. They were double the cost of an equivilant PC. It's an upsell. Every premium feature is rolled into a single computer that costs a lot of money. Because these features are usually only required individually, being unable to aquire them individually is a big disadvantage. And now that x86 dual-core processors are available, you don't even have to do without the performance advantage.

"The G4 is slow in relation to what is out there now, but still has more power than other chips when configured at the same speed."

That's not true. Pentium Ms and Athlon64s are faster by a factor of 2 at integer performance at the same clock speed, and their FP performance advantage is also substantial.

"BTW, my Powerbook used to get about 5 hours before the battery started showing its age, which was way better than any PC notebook available at that time."

PC laptops now have battery lives in excess of 7 hours thanks to Pentium M, and they get better performance on top of that.

"For 2 years now, Apple has held the top customer satisfaction rating"

Given the tendency of Apple users to express satisfaction with performance that would cause dissatisfaction with others, I don't consider a voluntary survey to be a reliable indicator. For example, the Macintouch reliability survey had people trying to inflate Apple's good results.

I think there's plenty of PC users that would have bought crappy machines and not taken care of windows, and it's not hard to imagine them being happier with a Mac, but for more demanding situations I've found Apple's offerings wanting. I know a lot of people that were burned by the iBook problems that have switched back. These things put people off permanently, and they have to be addressed.

A niche player can afford to offer a few specialized machines. As long as Apple refuses to diversify, they will never be more than a niche player.

Re:Apple's poor choice of using "Asus."

[JackAxe]

I've seen it on sites like Macslash and Ars Technica, with plenty of people posting to say they've experienced it. That's not a large study, but it's common enough for relatively small sites like that to get people chiming in.

Apple should do the right thing and fix their issues. I saw 480 names on that petition, a small percentage compared to the overall PB owners, but still enough to warrent a fix. This is just me, but since Macs do come at a cost, I always buy the Apple Care. $300(Or it was $350) extra is a small price to pay, when each of my PB's cost $3200 at the time. Besides my wifes brokent hinges, I've never need to use it, but It's a safety net I would recommend to anyone, so if they did experience a problem like the one above it would be fixed no questions asked.

I wonder if those peeps have dont things like unplugged all the RAM, reset the PMU manually and reset the OpenFirmWare? Generally these things will fix anything but a true hardware issue.

I would consider a "major bug" to be one that prevents me from doing what I need to do. If the guy had to use a Linux machine to finish the post, it prevented him from doing what he needed to do.

Well put and this is why I can rely on my Macintoshes, they've never got in my way with critical bugs. My friends have reliable PCs also, but the main difference between their reliablity any mine, is that there's takes effort and lots of know how.

That's true. But Debian-stable will do many times better than OS X.

But will it run Photoshop. ;) I have no doubt that a Linux peeps that know their system in and out can produce a rock solid system, but that would not be me. So OS X in its later builds is the best choice for someone like me.

That's not true. Pentium Ms and Athlon64s are faster by a factor of 2 at integer performance at the same clock speed, and their FP performance advantage is also substantial.

I stand corrected on the Pentium Ms, I had forgot about the newer Dothan chips. The earlier PM's(From last year and earlier.) were slugs across the board. But the big issue I have with Pentium Ms, and I'm hoping will be resolved when the Dual-Cores are released, is their lack of a SIMD. When Altivec is in play, a G4 can easily beat out the best Pentium M currently available. OS X uses Altivec to help accelerate the GUI, and it provides a massive advantage for things like video encoding. Basically all multimedia is accelerated by it. Certainly a Dual-core or Single-Core PM with a SIMD will be faster in all aspects, but until they're available, a G4 portable, still offers a clear performance advantage for peeps like me.

I didn't know they were making A64 notebooks. Are they like my friends "desktop replacement" 17" Alienware? A notebook that's so huge, that I literally thought it was a flatbed scanner. He gets less than an hour on one charge. And the part that made me laugh, was that this barely-portable-beast-of-a-machine, didn't include built-in wi-fi. He had to buy a PCMCIA card for that option. I just found one, lots of bang for the buck, but too huge for my taste and it's plastic. :p

PC laptops now have battery lives in excess of 7 hours thanks to Pentium M, and they get better performance on top of that.

Yep, tis just another reason why Apple is switching, great battery life. But 2.5 years ago, no PC notebook was available that could get 5 hours. :) But as usual things change. And just a rant I have about the Centrinos that offer greater than 7 hours of life; I'm not sure if this is normal, but my friend's work gave him an IBM Centrino, and the batttery was sooo huge, that it was sticking out the back of the computer.

Given the tendency of Apple users to express satisfaction with performance that would cause dissatisfaction with others, I don't consider a voluntary survey to be a reliable indicator. For example, the Macintouch reliability survey had p

Re:Apple's poor choice of using "Asus."

[ArbitraryConstant]

"This is just me, but since Macs do come at a cost, I always buy the Apple Care. $300(Or it was $350) extra is a small price to pay"

I don't have a problem with occasional problems that Apple fixes under warranty, so Apple fixing occasional problems under warranty isn't enough to satisfy me. I have a problem with reliability so low that there's months of downtime involved whether or not it gets fixed. With availability that bad it hurts the computer's usefulness even when it's up and running, and it is an enormous inconvenience.

"But the big issue I have with Pentium Ms, and I'm hoping will be resolved when the Dual-Cores are released, is their lack of a SIMD."

This is simply wrong. Pentium Ms have SIMD support.

"When Altivec is in play, a G4 can easily beat out the best Pentium M currently available. OS X uses Altivec to help accelerate the GUI, and it provides a massive advantage for things like video encoding. Basically all multimedia is accelerated by it."

The Altivec implementation on G4s is considered to be pretty good and the SSE implementation on Pentium Ms is considered mediocre, but between their clock speed advantage and the fact that G4s are terrible at everything else they aren't at an advantage, even for things like encoding video.

"I didn't know they were making A64 notebooks"

They're sold under the "Turion" brand name.

"I don't mind a niche for hardware, when it means better quality, and things like true software and hardware integration. And fortunately now days, buying a niche machine doesn't mean a lack of software, as it did a few years back."

Well, you've pretty much defined yourself as falling within the niche, and I don't buy the claim of better quality. What about everyone else? Dell, for all their faults, doesn't disable the second display in firmware to get people to buy a $2000 computer.

Re:Apple's poor choice of using "Asus."

[JackAxe]

See I've never had any downtime on my OS X Macintoshes, besides the time spent to install Panther and Tiger of course. You definitely had a lemon, and that sucks. Apple is to blaim, no buts about it.

I'm a "tard," I misread the statement about the Dothon's SIMD. They were saying it didn't include SSE3, where as SSE2 is present. Still a rather weak SIMD when compared to AlitiVec though. But over all the PM definitely has some punch. It will be nice for the one game I play on my PB; Warcraft 3. Just not as good for video in its current form. Anyways it wil be a nice upgrade now that some of my ignorance has been washed away. I was worried about loosing a SIMD. :)

True, Apple does do some Sony type things, like intentionaly disabling features. My G5 is an example of their meddling; It shipped with a Pioneer 108a DL burner, but Apple flashed it with their own firmware and labeled it a 107(something) if I recall, and disabled support for higher burn speeds, and DL burning. I figured that they would unlock it when Tiger was released, since it would finally offer support for DL burning from the desktop. They have offered firmware updates for past SuperDrives that added extra speed as an example. I guess that since the G5 didn't reach the speeds they were hoping for, the only thing they could really add when they released the DP 2.7 was DL burnning support. (Woooo hoo, big upgrade.) Anyways, they did not offer a firmware update to unlock my drive. The FW update they did release actually would've crippled it further. (Thanks Apple!!!) Anyways, I flashed my burner with an app some peeps wrote, and now it's running wtih all of its features.

I have my gripes about Apple, but since my OS X Macs have always worked so well, I'm willing to forgive these wrongful annoyances.

Dell just makes it a pain in the arse to install a secondary video card with their "cheap" consumer comps. This is a problem I ran into at my friend's office. He spent all day on it before calling me, an artist for help. I got it working after 2 hours. Never before have I ever had that issue with any comp. On all my PCs, it was a simple plug-in, boot-up, install any necessary drivers, and eveyrthing was happy. And there's also that Dell Axim I bought, it's the worst PDA I've owned.

Just an obervation about Dell products in general; They must use the cheapest plastic to cut cost. Have you ever noticed that most o their product make an egg breaking noise when moved? Other plastic products make a slight noise, but not as bad as the Dells I've checked.

Apple should probably consider selling a consumer tower for games and peeps like you when they switch to Intel. Not everyone needs a $2000 entry level workstation.

Hey, "if" you ever buy another Macintosh, trust me when I say they're not the crap that was that G3 iBook. I highly doubt that you would tread down that path again though. PCs are better for Linux anyways. :)

Re:Apple's poor choice of using "Asus."

[ArbitraryConstant]

"Apple should probably consider selling a consumer tower for games and peeps like you when they switch to Intel. Not everyone needs a $2000 entry level workstation."

I think it's pretty unlikely. There's nothing preventing them from doing it now.

anonymous slightly pseudo theo-coward responds

[Anonymous Coward]

you miserable retard.... $%$#%^ your mother and the horse she rode in on! :)

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

[JetTredmont]

I would have rpefered Apple going with AMD opteron's or contracting one of their other beefy 64 bit chips. Why intel?

1. Because Intel can bankroll transition costs to a large degree, as they benefit greatly from it.

2. Because people know Intel, not so much AMD. If you're going to say you're going to industry-standard chips, it makes sense to say you're going to the industry-leading (in terms of sales and marketing, not necessarily current performance) vendor.

3. Because Intel has a full spectrum of chip solutions, from XScale to high-end Pentium "5" architecture.

4. Because if Intel doesn't deliver then Apple can shift over to AMD quite quickly and easily.

NEWS FLASH! Mach has poor performance

[Anonymous Coward]

Welcome to 10 years ago...

http://i30www.ira.uka.de/research/documents/l4ka/1 995/ukernel-construction.pdf

Faster is not the same as better

[pammon]

Why do you (and AnandTech) conflate "faster" with "better?" I haven't read the Moshe Bar article you mentioned because it requires significant registration hoops, but there are numerous design decisions that Apple makes that impact performance.

OS X always links libc dynamically. OS X allows for floating point and SIMD in the kernel. OS X gives the kernel its own address space. Etc. There's a tradeoff between performance and binary compatibility/flexibility. In each of the above cases, Linux prefers the former, and Apple the latter. The Anandtech article makes no mention of these; their implicit conclusion is that Apple's engineers are incompetent.

And incidentally, Apple has done a great deal of performance work in their kernel.

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

[Courageous]

Well, they possibly could. The other speculation is that they're hoping to make use of some of the Palladium infrastructure to keep people from pirating the OS. Frankly, I don't think they should.

I know that there have been screenshots out there proving that OSX works on AMD just fine. So who knows what Apple might do. Just be aware: Apple switched away from IBM for a variety of reasons, but chief amongst them was that they couldn't get low power G-whatevers out of IBM.

C//

PURE BULLSHIT --APPLE NOT USING PENTIUM IV.

[Anonymous Coward]

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.

try oracle, performance is awesome

[Anonymous Coward]

Well Oracle 10g seems to be pretty good:

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

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

This article is wrong!!!!

[Hakime]

I think that this article is full of mistakes that are done by purpose (i dont know, maybe!!) or are due to the misunderstanding of those guys about many computing ideas and principles. I really think that such articles that claim to be informative should not be allowed to be on internet as it is simply saying wrong things. My big concern about their tests is that they are not fair and they never tend yo be fair to the apple side and osx. For example i believe that everyone who pretend to make precise testing should realize that if they got results that differ so much and are so unexplained, well the best thing is to try different testing methods and tools. So tools may work well for a given platform, others may not work well. So any tempt to highlight any os design flaw should be done after testing many different benchmarking tools. They don't do that, instead they try to find some reasons that are completely meaningless in the sense that they are saying things that are technically wrong. Trying to find such whatever threading problems in osx in order to hurt the platform is not really fair...... So to begin with, let me comment on the Apache results. Well they use Apachebench to test osx, and they get rather low request per second with osx. Well ok, but why don't they try something else to test Apache performance, in that case they could figure out that the problem is either the os or the benchmarking tool (they recognize themself that apple did tell them that thre is a bug in ApacheServer, while running it on osx, maybe? i did not test it). Try to run WebBench on osx and linux ppc or x86, and have a look to the results. Well WebBench is a largely accepted benchmarking tool for test Apache performance, so it make sense to use it too. pcmag.com have tested a Xserve G5, http://www.pcmag.com/article2/0,1895,1630329,00.as p, and their result show something like almost 8000 request per second for 60 clients for a static configuration test. Ohhhh!!!! What's going on here? What we have here is something completely different, a completely different image compared to their results. What does this tell us? Well two different bench tools can produce very different outputs. But moreover everything that follows in their article simply collapse because nothing tell us that the tools that they use for MySQL testing are not having a problem too. Moreover WebBench involve as weel many threads creation, so their theory about this threading problem of osx collpase too. We simply dont get any global image of osx performance in server applications with their limited set of bench tools. Did they never think that the problem of those results could come from the benchmarking tools or the app itself that may have performance problems while running on osx. Here is the comment of pcmag.com "Performance-wise, the dual-processor Xserve G5 compares well with Linux-based x86 servers. This is not surprising, considering that Mac OS 10.x is based on FreeBSD UNIX. Using the included Apache server, we ran the Xserve G5 through our standard WebBench tests. It did quite well on the static WebBench test, outperforming a competitor's dual processor x86-64 server running Apache server on SuSe Linux-64." Something rather different to their general statement, isn't it? So now about MySQL. So first they mention fsync(). Let me correct. What are they talking about is wrong?, fsync() behaves the same as it does on all unixes: it writes the data from the host to the drive. However this is not good enough because drives will buffer the data and potentially write it in a different order than the app did. To deal with this, MacOS X provides an fcntl() called F_FULLFSYNC which does what fsync does and in addition asks the drive to flush all buffered data to disk. This is the only way for an app to be able to make any guarantees about things like transactions which is why InnoDB in MySQL uses it! And i think that because its an os feature it works whenever you use MyISAM o

Re:This article is wrong!!!!

[calyphus]

Paragraphs were invented during the middle ages. You might consider using them. Readers might then consider reading part of your ramble.

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

[Deadguy2322]

The reason Apple went with Intel was simple. Intel could provide a complete chipset solution, not just a CPU. Intel has the production capacity to supply 1:1 a complete sboard+chip for every order placed. AMD just makes CPUs, and usually not enough to meet demand. Besides, just because the Dev units are P4s, do you really think that the chip for the MacIntels is just going to be an off-the-shelf x86?

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

[Anonymous Coward]

> And I can't wait to move over a bunch of older intel's to mac os X. ;)_

Sorry, but it has been already in the tech news that Apple will have a special DRM chip in the Intel system. The x86 OSX simply won't install/work on your older machines.

But did you expect anything else? Apple hardly would shoot their hardware business in the head like that...

Missing the bigger picture.

[argent]

But there are no portable machines with the G5 processor.

There are also no portable machines with the e600 processor, the new G4-cored chips coming from Freescale. Why not? Because they're only just getting to the sampling stage.

These chips should be to the G5 what the Pentium M is to the P4: a small short-pipeline core that gets more work done per clock cycle, tied to a high bandwidth bus. Intel finally caught on that it's not so muc about CPU speed any more as it is about I/O bandwidth... and went from a 133 Mhz FSB to a 533 MHz FSB and the resulting chip made the P4 look poorly. Freescale's going from 166 MHz to two 768 MHz memory busses and separate PCI-X ports on-chip... which should give any P-M a run for its money even at 3/4 of the CPU clock speed.