Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
OS X Businesses Operating Systems AMD Software Apple Linux

G5 vs. x86 and Mac OS X vs. Linux 486

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."
This discussion has been archived. No new comments can be posted.

G5 vs. x86 and Mac OS X vs. Linux

Comments Filter:
  • Wow, double flamewar.
    Slashdot editors are impressive :)
  • by c0l0 ( 826165 )
    Linux 2.6.5 - That's rather outdated... Maybe more recent kernel snapshots offer better performance in some regards?
  • by Noksagt ( 69097 ) on Friday June 03, 2005 @04:59PM (#12717787) Homepage
    The article also takes a look at performance under OSX versus Linux.
    They look at PowerPC running Darwin 8.1 and two Xeons and an Opteron running Linux 2.4/2.6. Why not show the PowerPC running Linux?! I want to see how Linux on PPC compares to Linux on x386 these days!

    Anyway..here's the article summary:
    Mac OS X is incredibly slow, between 2 and 5(!) times slower, in creating new threads, as it doesn't use kernel threads, and has to go through extra layers (wrappers). No need to continue our search: the G5 might not be the fastest integer CPU on earth - its database performance is completely crippled by an asthmatic operating system that needs up to 5 times more time to handle and create threads.
    So, forget OS X in the server room, but have fun if you want a desktop OS.
    • by fimbulvetr ( 598306 ) on Friday June 03, 2005 @05:01PM (#12717810)
      Don't forget this:

      The server performance of the Apple platform is, however, catastrophic. When we asked Apple for a reaction, they told us that some database vendors, Sybase and Oracle, have found a way around the threading problems. We'll try Sybase later, but frankly, we are very sceptical. The whole "multi-threaded Mach microkernel trapped inside a monolithic FreeBSD cocoon with several threading wrappers and coarse-grained threading access to the kernel", with a "backwards compatibility" millstone around its neck sounds like a bad fusion recipe for performance.
      • I think Sybase and Oracle found the linuxthreads package :) FreeBSD 4.x and early 5.x had problems with multithreaded applications like mysql, which has been solved in the newer versions. That's what the article says as well:

        "This means that applications use slower user-level threads like in FreeBSD and not fast kernel threads like in Linux. It seems that FreeBSD 5.x has somewhat solved the performance problems that were typical for user-level threads, but we are not sure if Mac OS X has been able to take advantage of this.

        In order to maintain binary compatibility, Apple might not have been able to implement some of the performance improvements found in the newer BSD kernels."

        Yes, server performance with the xserve seems terrible right now, but I think that will be solved in the future, as apple will incorporate the enhanchements from fbsd 5, and more importantly 6. They are cooperating (freebsd and apple) it seems on many issues.

    • This just proves the point that we're ready and willing to deal with the greater overhead of a (semi) microkernel OS. The performance hits are bad, yes, but if the core of the system is more flexible and robust it's a small price to pay.

      Honestly, I know of very few machines out in the real world that are heavily taxed in ways where OS X suffers. I'm sitting next to a server room with 47 (mostly wintel) servers in it and not one of them has shown greater than 10% load on a five-minute scale for days. I'd ra
      • by lederhosen ( 612610 ) on Friday June 03, 2005 @05:13PM (#12717915)
        I totaly agree that they should have done a comparison using Linux/PPC.

        I would allso like to see them use the latest Intel compiler.

        I dont, however, agree on the microkernel stuff. darwin is no microkernel design at all, all the
        driver, filesystem and memory management is done
        in kernel space. There is nothing in that design that makes the OS more stable.
        • I think they should have gone all the way and used one of the distros that has ports for both x86 and PPC -- run the same software on both platforms. (E.g., Debian, Ubuntu, FreeBSD, etc.) Then you'd get to test out the hardware. This way, you have two variables: hardware and OS. If you want real benchmarks, you have to isolate these. First test a G5 running Debian against an Opteron system running Debian; then test a G5 running Debian against a G5 running OS X. Hey presto, results that actually mean s
        • Read the comments. The author of the article says Linux/PPC is his next piece.
        • ???

          I suppose these aren't the droids I'm looking for either? Nice try OBIWAN.

          Oh well, at least it wasn't modded informative.

        • Yeah...from the title I was guessing that the 3(4) benchmark machines would be:

          X86/Linux vs G5/Linux
          and
          G5/Linux vs G5/MacOS X

          But comparing

          G5/MacOS X vs X86/Linux just seems kinda weird.
    • They look at PowerPC running Darwin 8.1 and two Xeons and an Opteron running Linux 2.4/2.6. Why not show the PowerPC running Linux?! I want to see how Linux on PPC compares to Linux on x386 these days!

      Hey, that sounds familiar. I did some benchmarking [mac.com] two years ago and it got posted on Slashdot [slashdot.org]. Of course, people were flaming me there that I should be comparing Linux/x86 to OS X as the "native" operating system, and it was unfair to handicap the Apple hardware with something "not optimized for it".

      • That was 2001? I remember that like it was yesterday. Where the hell has my life gone?

        I'll say the same thing now that I (IIRC) said in the comments then: Your results gave me a far more favorable impression of Apple hardware than any of those contrived Photoshop tests ever did. Basically, you compared Linux on a platform where it's supported by, oh, three main developers to Linux running in its own back yard, and essentially got a draw!

        I think it spoke very highly of the Apple hardware of the time, as wel

    • by dduck ( 10970 ) on Friday June 03, 2005 @05:17PM (#12717960) Homepage
      Your Linux on G5 performance figures are here [ibm.com]. It does appear that the performance (or rather, lack of wrt. forking and threads) is due to tue architecture of Darwin/OS-X.

      I will point out that this is hardly relevant for a desktop OS, and that I am more than happy with my dual G5/1.8GHz. Getting things done faster and neater due to elegant interaction design is much more important to me than being able to spawn threads quickly ;)

    • by RickHunter ( 103108 ) on Friday June 03, 2005 @05:18PM (#12717970)

      Except that they used Apache 1.3 and MySQL, two of the worst possible choices. If they'd gone for Apache 2.x (which actually uses threading, instead of processes) and PostgreSQL, things would've looked much nicer.

      • MySQL uses threading, PostgreSQL uses multiple processes. Given that the MySQL performance was so bad, I don't think Apache 2 would have helped. And, if anything, PostgreSQL would have run even slower than MySQL.
    • I want to see how Linux on PPC compares to Linux on x386 these days!

      Well, anandtech, nor most of the other hardware comparison companies would provide reliable data to you. Considering that they used gcc for the Linux benchmarks instead of a performance compiler like Intel's, PathScale's, or the Portland Group's, I would assume that they would use gcc for a PowerPC and x86 comparison as well. My psychic forecast is that the PowerPC would outperform the x86 setup because Apple has tuned gcc for the Power
      • How is using gcc not a fair comparison? What other compiler are all your apps going to have been compiled with?

        Maybe a big vendor like Oracle or Sybase will have invested in say the Intel compiler, but your average end user or developer most certainly won't have done so, and nor have any of the distros.
      • My psychic forecast is that the PowerPC would outperform the x86 setup because Apple has tuned gcc for the PowerPC platform.

        Which would probably even things up, if anything. Remember that GCC's largest user base is probably x86, and most of its developers are probably working on x86 PC's. So it stands to reason that a lot of work has gone into the x86 optimisations in GCC over the years. But, they're very different CPU's (translated-CISC vs kinda-RISC) so different things have to be done to optimise

    • Or, what would have made a whole lot of sense would be to put BOTH a Mac running Linux and one running OSX in the tests. Like, Redhat vs. YellowDog vs. OSX. That way, we could draw out better what's an issue of hardware and what's an issue of software.
    • They look at PowerPC running Darwin 8.1 and two Xeons and an Opteron running Linux 2.4/2.6. Why not show the PowerPC running Linux?! I want to see how Linux on PPC compares to Linux on x386 these days!

      Probably pretty good, considering Linus Torvalds' primary machine is a PowerMac G5 running Linux [slashdot.org].

      Bottom line - with Linux as the operating system, all indications are that the G5 and the Opteron reign supreme over Intel's quaint little offering, and that the G5 will blow the doors off clean off Opteron i

  • Flawed comparison (Score:4, Insightful)

    by Amoeba ( 55277 ) on Friday June 03, 2005 @05:00PM (#12717791)
    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.

    • by Medievalist ( 16032 ) on Friday June 03, 2005 @05:22PM (#12718010)
      That comparison is easy. OSX hacks a BSD kernel into a Mach microkernel [wikipedia.org], and thus performance is nearly as bad as Mach despite the existence of the mature, standardized interfaces of a BSD.

      MacOSX is not about performance. It's about interface. I don't think Apple (or Next for that matter) has ever tried to deny their intention to overcome the performance problems caused by tremendously complex software through the use of immensely powerful hardware.
      • by hkb ( 777908 )
        Are you retarded? Go read the link YOU provided. And then go Google, specifically kernelthread.com, where they discuss how that although they use the Mach 3.0 kernel, they've eliminated most of the performance hits by highly integrating the BSD subsystem.

        dumb ass.
    • 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.

      Its well known that benchmarks are excellent at producing benchmark scores.

      I'm guessing the parent didn't read the article, because some of the benchmarks were low level things like memory access and assembler math stuff. These things do not make kernel system calls.

      I will say that the threading issues were interesting. Looks like Apple nee
    • What performance is he measuring? The hardware or the OS?

      Since nither the hardware nor the OS can operate without the other, I'd call it sensible to compare configurations that people might considering using in real life. In fact I don't even know what you mean by a "baseline"; OSX won't run on anything else, and linux is of course not exactly the same on different platforms (if it were, it wouldn't run!)

      Besides, the conclusion seems clear enough to me: OSX has some performance problems that precl

    • Yeah, as others said, why don't you read the article? Care to explain why this comparison is flawed?

      Since Apple sells xserve with an os x supposedly tuned for servers, in other words, it sells it as a package, it absolutely makes sense to compare it with other solutions. Whether fanboys like the results or not (and even if some have spare mod points to moderate a comment "insightful" even though except for stating that "the comparison is flawed" doesn't say much)

    • Re:Flawed comparison (Score:3, Interesting)

      by Flamerule ( 467257 )

      This comparison is flawed. A more direct comparison that would have resulted in better information would have been Mac/OS X vs. x86/BSD.

      It's not flawed. Perhaps they'll undertake your comparison some other time.

      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.

      What a crock of shit. Guess what, buddy -- he's measuring the performance of both at the same time! *gasp*

      He takes the mo

    • He appears to be measuring the scheduling performance of the OS and the compiler optimization, not the performance of the hardware itself. So yes, it is comparing apples to oranges.
  • Summary (Score:5, Informative)

    by varmittang ( 849469 ) on Friday June 03, 2005 @05:02PM (#12717817)
    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.
    • Re:Summary (Score:5, Informative)

      by kylef ( 196302 ) on Friday June 03, 2005 @10:17PM (#12720153)
      The G5 woops when it comes to floating point, and stays just behind in everything else.

      Uh, that's not what I read:

      The conclusion is that the Opteron has, by far, the best FPU, especially when more complex instructions such a FDIV (divisions) are used. When the code is using something close to the ideal 50% FADD/FSUB and 50% FMUL mix and is optimised for Altivec, the G5 can roll its muscles. The normal FPU is rather mediocre though.

      That hardly sounds like the G5 is "whooping" when it comes to floating point...

  • by HeelToe ( 615905 ) on Friday June 03, 2005 @05:03PM (#12717821) Homepage
    How about OpenDarwin x86 vs. Mac OS X on Apple Hardware?

    How about Linux on x86 vs. LinuxPPC on Apple Hardware?

    jeesh
  • First (Score:3, Funny)

    by pocketfullofshells ( 722066 ) on Friday June 03, 2005 @05:03PM (#12717825)
    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 [amd.com] on them. that's why i buy them
  • by 3770 ( 560838 )
    I'm not a Mac Zealot, lets start with that.

    But they are running a test and are identifying the thread creation as being really slow on the Mac and that that is the cause for the Mac's slow performance on the MySQL test.

    Come now, if you are running software that is slow because you are creating threads all the time then you need to change software.

    Use some kind of threadpool and *kaping*, problem is gone.

    This is more revealing for MySQL than it is about Mac OS X.
    • Ummmm...... (Score:3, Interesting)

      by dmaxwell ( 43234 )
      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?

      • No,

        The point is that MySQL would run even faster if it used a thread pool.

        I don't know the internals of MySQL so maybe I'm mistaken and they use a thread pool. I'm just basing my information on the article.

        I'm wondering if I'm having a brain lapse and I'm missing something. Because what I read is that the system is slow because of creating threads, and Apple had three people helping out with the tests and they are unable to explain what I wrote in my grand parent post.

        Am I missing something?
      • Nah, just don't run MySQL on Darwin/OSX. Problem solved. Remember trolls, OSX is a desktop operating system. It's perfectly fine for desktop, workstation, or group webserver use. By the time you need to handle ten thousand simultaneous http requests, consider FreeBSD/x86 or NetBSD/PPC.
        • Re:Ummmm...... (Score:3, Informative)

          by ad0gg ( 594412 )
          By the time you need to handle ten thousand simultaneous http requests, consider FreeBSD/x86 or NetBSD/PPC.

          Umm. No. I'd pick linux running on opteron system.

  • by Anonymous Coward on Friday June 03, 2005 @05:05PM (#12717844)
    Until I saw the blatanly placed & scantily clad woman with the words "Root Me" written with MS Paint on the desktop.
  • "he PowerPc 970FX is a very wide, deeply pipelined superscalar monster chip, with excellent Branch prediction and fantastic features for streaming applications. And let us not forget the two parallel FPUs and the SIMD Altivec unit, which can process up to 4 calculations per clock cycle."

    The PPC970FX/G5 looks really hot, even up against Intel and AMD's top CPUs. I'd love to see such a direct comparison as this report with an extra couple of columns for nVidia and ATI's top-end GPUs. Sure, they don't run Dar
    • Are you suggesting we run a general purpose OS on a GPU? That doesn't sound like a good idea, even if it were possible. Sure, the GPU's coming out of ATI and nVidia have a lot of theoretical processing power, but it's really mostly only for doing vector calculations (vectors, colours, etc) on massive amounts of independent data. And with little or no branching. It's your classic SIMD setup. The shader programs are explicitely limited in the data they can access, so they can easily be run in parallel. The l

  • 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 ke
  • by UnapprovedThought ( 814205 ) on Friday June 03, 2005 @05:18PM (#12717971) Journal

    As some people have pointed out (but not completely), you should be comparing:

    • PPC vs. x86 on Linux, or
    • PPC vs. x86 on BSD, or
    • Linux vs. OSX on PPC, or
    • Linux vs. OSX on x86(!), or
    • OSX vs. Windohs on PPC, or
    • OSX vs. Windohs on x86
    • x86 vs. PPC for TPM/DRM BS
    • PPC Altivec vs. x86 SSE3 on Linux

    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.

    • by Atomizer ( 25193 ) on Friday June 03, 2005 @05:50PM (#12718283)
      There's no OpenLinux, FreeLinux or NetLinux. I think that proves that *BSD forks at least 3 times faster than Linux.
    • Linux forks 5 times faster than BSD, but that's been known for years.

      Hmmm... where did you read that? Even in the fefe test, freebsd and linux have very similar performance characteristics, and that's a two year old benchmark.Quote:

      "FreeBSD looks like it would scale O(1) if I could create more processes with it, but as long as I can't confirm it, I can only give it the second place.

      "

      Check the graphs [bulk.fefe.de] ... and the corrections (author did not read man tuning, sysctl, the handbook... well, the documenta

    • 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 Syst

  • by mark_wilkins ( 687537 ) on Friday June 03, 2005 @05:19PM (#12717978)
    "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
  • I happened to be passing London today and popped into Apple's flagship store. All very nice, but I idly hit F12 in order to bring up dashboard on one of the Powerbooks - 15" or 17" I think - and it was sloooooow.

    Now, this could be down to a dozen factors, and it only slightly deflated my ambition to own a nice shiny mac - perhaps a macmini - but it wasn't a good thing, that's for sure.

  • "I am no operating system expert, but with the data that we have today, I think that a PowerPC optimised Linux such as Yellow Dog is a better idea for the Xserve than Mac OS X server. "

    I'd like to see these benchmarks rerun with the G5 running the same OS as the other CPUs: Yellow Dog + kernel v2.6.5. The Darwin vs Linux competition makes deriving real info about just the hardware impossible, though an interesting aspect of the review.
  • from our fine folks at the Texas Advanced Computer Center:

    At the presentation, they mentioned the G5's potential, but noted that it was closer to the Intel architecture in the sense that each CPU shared a memory controller (but it's not hampered by the bus). The Opteron's HyperTransport model is simply more scalable. Apple got the point, but whether they will address this deficiency in

  • The compiler used to compile the benchmarks makes a huge difference. I'm very disappointed that information about the compilers wasn't published in this "review". This makes me suspect that GCC was used. Performance of GCC-compiled code varies widely across platforms.

    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,

  • MacGCC? (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Friday June 03, 2005 @05:24PM (#12718020) Homepage Journal
    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.
    • Most of the benchmark data is bottlenecked by gcc, as the review mentions.
      The biggest problem for servers was the poor threading performance. That's not the compiler's fault, it's the OS.
      • I didn't say an appropriate compiler would fix the biggest problem. I said it would show off the Altivec, which is the PPC's biggest HW advantage. Threads would still be slower, but at least the FPU would get a fair shake. I pointed out that the review should have heeded its own last words, using 2.6.5 Linux on all the HW units, in another post [slashdot.org] in this thread. That would make thread comparisons of the CPUs useable.
    • Re:MacGCC? (Score:2, Informative)

      by bubba451 ( 779167 )
      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.

      Good news! Apple has been doing precisely this with its contributions to auto-vectorization [gnu.ghks.de] in GCC 4.0 [apple.com].

    • Re:MacGCC? (Score:4, Insightful)

      by mr_burns ( 13129 ) on Friday June 03, 2005 @07:31PM (#12719129)
      Apple actually does work on GCC and it gives patches back to the project. The way they do this was actually used as a counterexample in the recent khtml/webcore spat.

      I think that a better choice on OS X Tigger would have been GCC 4 for this test, as that's what the OS is built with and it's the native compiler for the OS.. IIRC.
  • ...so you don't have to read it: Apple = slow, Linux = the shit.

    Now, had they gone x86 BSD on the G5 versus OSX on the same G5 then that would be a bit different. But nobody ever does that. I'm glad I'm not the only one who saw that "comparison" was flawed a bit. But it is still nice to see the myth of Apple being all-powerful being demolished by cruel charts. ;)
  • but chances are "energy waste" didn't come up...

    If my AMD64 can get me 30fps in ut2k4, compile the kernel in under a minute or two and render porn at acceptable jerk rates...

    WTF DO I CARE!

    Its doing all this while taking a quarter the power of the G5. All I know is my AMD64 doesn't have a windtunnel in the case to keep from melting through the board.

    Efficiency people, not raw numbers.

    If you can do X amount of work with Y less power in a comprable amount of time... that's a good thing as Y increases.

    To
  • I would really like to see a comparison using better compilers though, Intel on x86 and IBM on Power.
  • ARG! gcc 3.3.3 (Score:3, Insightful)

    by Duncan3 ( 10537 ) on Friday June 03, 2005 @05:40PM (#12718164) Homepage
    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".
  • 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
  • In many benchmarks, the results essentially break down to which hammer, using a swing of X velocity from Y distance with an arc of Z, will drive a threepenny nail N millimeters into a pine block. And they're very useful if you want to drive threepenny nails into pine blocks while swinging from Y distance with a Z arc at X velocity.

    And in some cases, you really do want to do that. 80% of the time, you'll be pounding threepenny nails into pine blocks. So this particular benchmark is going to tell you whi

On a paper submitted by a physicist colleague: "This isn't right. This isn't even wrong." -- Wolfgang Pauli

Working...