Slashdot Mirror
G5 vs. x86 and Mac OS X vs. Linux
demonbug writes "Anandtech has an article up comparing performance of dual G5s to AMD Opteron and Intel Xeon workstations. The article also takes a look at performance under Mac OS X versus Linux. It provides an interesting look at some of the strengths and weaknesses of the different CPUs." From the article: "This article is written solely from the frustration that I could not get a clear picture on what the G5 and Mac OS X are capable of. So, be warned; this is not an all-round review. It is definitely the worst buyer's guide that you can imagine. This article cares about speed, performance, and nothing else! No comments on how well designed the internals are, no elaborate discussions about user friendliness, out-of-the-box experience and other subjective subjects. But we think that you should have a decent insight to where the G5/Mac OS X combination positions itself when compared to the Intel & AMD world at the end of this article."
Wow, double flamewar. :)
Slashdot editors are impressive
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Linux 2.6.5 - That's rather outdated... Maybe more recent kernel snapshots offer better performance in some regards?
:%s/Open Source/Free Software/g
YTARY!
Anyway..here's the article summary:So, forget OS X in the server room, but have fun if you want a desktop OS.
This comparison is flawed. A more direct comparison that would have resulted in better information would have been Mac/OS X vs. x86/BSD.
What performance is he measuring? The hardware or the OS? Comparing both with no baseline control for each is about as informative as pulling numbers out of my ass.
Do not taunt Happy-Fun Ball
The G5 woops when it comes to floating point, and stays just behind in everything else. AMD of course takes top honors in almost everything. The find out that OS X kernel doesn't do so well on the server when it comes to multiple threads created while using MySQL and other possible open source software, so they conclude OS X a good desktop, but Linux is better on the Server. They will look into Linux on PPC to see which is better next time, PPC or x86 when it comes to a Linux server.
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
How about OpenDarwin x86 vs. Mac OS X on Apple Hardware?
How about Linux on x86 vs. LinuxPPC on Apple Hardware?
jeesh
Anandtech has an article up comparing performance of dual G5s to AMD Opteron and Intel Xeon workstations.
Ok, Rule #1 - its a performance comparison...
It is definitely the worst buyer's guide that you can imagine. This article cares about speed, performance, and nothing else!
Calm down, did we forget Rule #1 already?
No comments on how well designed the internals are, no elaborate discussions about user friendliness, out-of-the-box experience and other subjective subjects.
OK... Rule #2, no more posting news for you.
I wonder if he uses a mac or pc....
are opterons are super super fast and AMD kindly, and without NDAs, provides technical documentation on them. that's why i buy them
vodka, straight up, thank you!
Agreed. Once they'd found that the kernel was crumbling when there were lots of threads, why did they not try the same tests on Linux/PPC?
Try Corewar @ www.koth.org - rec.games.corewar
Until I saw the blatanly placed & scantily clad woman with the words "Root Me" written with MS Paint on the desktop.
Don't forget the
"The people who buy Macs are creative professionals" partyline that we've been hearing since Joel was still on the S.O.L.
do() || do_not();
I read through the whole comparison/review. The article points out that the main factor that MySQL is slow on OS X is how threads are handled in darwin. It's a speculation based on good observations. However, I think that the author should have done a more controlled test to prove his point, such as running yellowdog linux and OS X on identical hardware to compare MySQL performance. Instead, the mahcines that ran linux were opteron and xeon machines, which made it hard to tell whether the hardware or the kernel contributed more to the performance difference.
MySQL runs just fine on the BSDs, Linux, and even Windows. Every project on the face of the planet that uses threads has to be re-written for the sake of Darwin/OS X?
Try this similie on for size, OS's are like socks. They're all fine at first, but after a while they all start to stink.
As some people have pointed out (but not completely), you should be comparing:
Linux forks 5 times faster than BSD, but that's been known for years. You didn't need a new benchmark/ad for that. Finally, the article doesn't have a benchmark that uses Altivec to its full potential, so it might be a hack piece as well.
"Thirdly, hardcore gamers are not the ones buying Apples, but rather, creative professionals.
So, we focus on workstation and server applications..."
How could anyone who has ever met a "creative professional" think they care about "workstation and server applications" like MySQL and Apache??
Sorry, guys, but being a sysadmin does not make you a "creative professional..."
-- Mark
Wouldn't it have been better to use compilers that are tuned for each platform? Say, Intel's compilers for the x86 systems, and IBM's compilers for the PPC systems. These compilers could perform better prefetching, for example, and you might get a more accurate idea of what the systems could do with binaries that are tuned for that system.
Most of the benchmark data is bottlenecked by gcc, as the review mentions. That's fair, because that's what so many of us use to compile on these kinds of platforms. But I do think that Apple would do well to throw some of their programmers at the GCC project, at least adding their expertise to some of the Altivec modules. It would show off their platform, and return some value to the gcc project surely used extensively by Apple.
--
make install -not war
Umm, no.
Linux? If I have never have to use vi to set up a simple routing configuration again, it will be WAY too soon.
vi? Where do you *have* to use vi? Is it meant to stand for [any plaintext editor]?
Granted, editing text configs *can* be less friendly in certain situations (it can also be a lot more flexible and straightforward); but I guess invoking the name of vi (which has a reputation for being arcane) makes textual config sound more complex than it actually is.
I use and like vi in preference to Emacs (vi IMHO is less friendly on the surface, but more straightforward than Emacs once you know the basic keys). BUT.... we're discussing its reputation here, and it seems this is being exploited to make your case.
Don't like vi? Use a different editor, but don't try to rub vi's alleged arcaneness off onto text editing in general.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Sorry, but this completely invalidates any metric including the word "performance".
IBM's C compiler should be used on the Mac side (OSX now uses GCC 4.x BTW), Intels C compiler on the AMD64 side.
Do that, and try again.
Repeat after me - "GCC is crossplatform - performance sucks on all eequally".
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
I want to hear about the techniques used by "the major database vendors" to deal with the thread blocking issue. Maybe programs like MySQL can take advantage of these enhancements, too.
This doesn't appear flattering for Apple, but it's apparent that they have been scrambling to get the user experience right in OSX, at the expense of sub-optimal kernel development. Hopefully they will be able to refocus on the kernel and the compiler and get the performance up to what Linux people expect. Thread blocking will become much more of an issue as multi-core CPUs become mainstream.
Linux is a good example of what can happen here. They got crummy benchmarks, the kernel guys identified the bottlenecks, experiments were written to overcome the bottlenecks, and eventually the fixes made it into the kernel and everyone benefits. Notice how Microsoft doesn't brag about performance any more?
Sunshine is the best disinfectant. - Tip O'Neill
There's no OpenLinux, FreeLinux or NetLinux. I think that proves that *BSD forks at least 3 times faster than Linux.
My investigation has uncovered a series of hippy drum circles arranged in a flower shaped pattern on this map (that you cannot see).
My research clearly shows that we are very close to the start of a hippy music festival. It could begin at almost any moment. In fact it may already be too late.
Appended to the end of comments you post. 120 chars.
The odds are pretty good that you'll need to do some CLI sorcery to get an X-Server to run under OSX.
Double-click on your hard disk.
Double-click on Applications.
Double-click on Utilities.
Double-click on X11.
Compare a machine running OS 8 or OS 9 to a Macine running OSX, the machine will be discernably slower when running OSX.
The interesting question is, why?
Here's what I've found:
Compare a machine running NeXTSTeP with a comparable machine running OS 8 (say, the Performa 475 vs the NeXTStation Mono). The NeXT, running the same basic kernel as OS X, is about as responsive for pure GUI interactions and WAY more responsive running multiple applications or when disk I/O is involved.
Compare a machine running BeOS and Sheepshaver with the same machine running OS 8 natively. Under BeOS, the machine is again more responsive, and again disk I/O is much better.
Compare a machine running OS 9 applications under Classic and the same machine running OS 9. Not a lot of difference. Slightly slower screen, better disk I/O, and much more responsive than OS X applications.
OS 8 vs OS 9? Not that big a deal. OS 9 does multitasking a bit better, it seems, but at the same time it's a bigger system.
OS X should be faster than OS 9, then, even with the "Microkernel overhead", because of the improved multitasking and disk I/O. But you can see that it isn't just using it on the same machine.
The big difference is that OS X allocates a separate raster map for each window, and composites them without involving the app. Scrolling panes in windows can end up using a raster map the size of the scrolling region. This means at least tens of megabytes of extra storage just on scrolling, and at least one and sometimes two additional copies (dpending on translucency) before any pixel makes it to the screen.
This is why QE and QE2d are such big wins on the Mac. They move one of the copies out of the way.
Meanwhile on OS 9, you usually have zero copies... the app calls Quickdraw and Quickdraw renders just what's visible, and may completely bypass the CPU to do it. Just like just about every other windowing system I know of, including NeXTstep.
That's not what I mean't.
You need threads. But you create 20 threads at the beginning (or something) and then you use those throughout the life of the application.
You can grow the number of threads dynamically to best suit your load.
But the point is, you don't create threads all the time. You pick a thread up from a thread pool.
Creating threads on Windows and Linux may be 5 times faster than on Mac OS X, but it is still a relatively slow operation. A thread pool makes sense there as well.
I'm not saying that it is OK that thread creation is slow. But creating a thread that lives for less than a second is a bad design for a server application.
Another poster stated that MySQL uses thread pools however. So that puts things in another light. If the problem wasn't because creating threads are slow, then Mac OS X had another problem.
The Internet is full. Go Away!!!
Holy crap! Where did you get the idea of comparing OS's to cars?!? Genius.
If metaphors were cars this would be the big honking overcrowded city bus that everyone's ridden and smells vaguely of urine.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Lamborghini? Did you read the article? They found that Linux was ten times faster for high-end server apps that make lots of system calls. That's more like comparing that old Charger to a shiny new bicycle. I love OSX's GUI too, but is it worth an order of magnitude speed penalty? On a server system? Hell no.
(I similarly dislike Linux and like OSX, so this article disappointed me. I do think they made some mistakes in their testing. However, the unerlying problems causing the performance issues are certainly real.)
isn't it sad that racist, homophobic and sexist comment systematicaly get rated funny on Slashdot?..
A comment can't be homophobic, only a person can.
I am not homophobic, and I see the humor in the joke you are replying to. It's called absurd humor... half the joke is in the stereotyping. Macs are stereotypically the favorite computer of gays, and Linux geeks have a strong correlation with the "dirty hippie" and "pinko commie" crowd.
So don't get your panties all in a bunch.
(I'm assuming you're either a P.C. blowhard, or a homo. See, wasn't that funny?)
Ironically, the word ironically is often used incorrectly.
Like everyone's already said: Linux/PPC would have been a good thing to add in. Like someone else mentioned, Apache 2.x and a PostgreSQL database would have been good tests along with the MySQL+Apache 1.3 ones. I haven't seen anyone mention the gcc compiler version.(they used 3.3) 3.4 is more wholesomely made. 4.0 is the latest, woulda been interesting to see if that made any significant changes(and doesn't panther use that defaultly?) The test lacks the ability to show whether the issues in server based MacOSX are CPU based or OS based. Linux/PPC would have been helpful.
Mach's multitasking _performance_ still blows.
Compared to OS 9? Have you used classic Mac OS? The classic Mac OS multitasking charade (I won't call it a kernel) was appalling. It had no real scheduler, applicatons ran for a while, gave up the CPU voluntarily, and went on. There was no way to get smooth interapplication concurrency because the API was built around operations that weren't even thread-safe, let alone safe for separate independent applications to use concurrently.
That's what I'm comparing Mac OS X with, not other real multitasking operating systems, but a hideous shambling wreck that was so bad it made a 240 MHz Power PC running Mac OS 9 feel less responsive than a 30 MHz 68040 running Mach.
Later on, I ran both OS 9 and OS X on the same hardware. OS X was smoother and more responsive in the face of even heavy competition for the CPU and disk than OS 9 just sharing files. I had an upgraded 7600 which I was going to use as a file server and occasional console, until I started trying to use it that way. Any time it started sharing files it got slow, unresponsive, and jerky. I wanted to use it for music, but iTunes would chop and skip on just about any file access. Upgrading it to a 240 MHz CPU and giving it a second SCSI card just for file sharing didn't help.
Bad as Mach is, it's so much better than what Apple was using before that if they had just stuck to using Quickdraw and Display Postscript OS X would have knocked the doors off OS 9 on the same hardware. I had a copy of Rhapsody DR1 for Intel at one point, and it was easily the equal of BeOS (another OS I've found has an inflated reputation) on the same test box.
It's not the Mach kernel that makes OS X slower than OS 9, it's the Quartz graphics.
The reason these tests ARE relevant is that the vast majority of users do not run Linux on their Macs, nor do they run BSD on their PCs.
The tests are pitting the common OS on each platform against each other. That is a fine comparison, because it represents the basic choice that people face when they want to choose a platform.
You just have to be careful how you interpret the results. Since neither the hardware nor the software are held in common as a "control" variable, there is no way to compare System A's software against system B's, or System A's hardware against System B's.
The best conclusion you can draw from a system level comparison like this one is that, given the test environment, System A was faster than System B overall.
And in this case, it looks like the G5-OSX combo is "System B"...
k, I don't know whether this "between 2 and 5(!) times slower" stat is true, but even if it is, it should hardly matter. The time it takes to create a thread should be insignificant compared to the time it takes for the thread to do its work (at least, in a good program). Not to mention that in the case of a multithreaded server (like Apache 2), thread pools are used so that less time is spent creating and destroying threads.
The bits on the bus go on and off... on and off... on and off...