I recently bought one of the new dual core PowerMacs. Having used the machine for a couple of weeks, I thought I would share some of my observations and feelings about it. First, let me get my biases out in the open. I have, for about four years, very happily used Linux on my desktop. Doing so has made me very comfortable with the UNIX environment in general, and with GNOME specifically. During that time, I have used OS X machines on a regular basis, so I am quite comfortable in that environment as well. Since I switched to Linux, I have not used Windows for anything more than the occasional bit of software testing or lab work, and generally feel quite uncomfortable with it. Thus, this article is very much written from the perspective of someone who finds OS X and Linux pleasing on principle. I implore the reader to make his own value judgments based on my comments.
I have two computers at the moment, a dual-core Athlon X2, which I will refer to as the “X2” from here on, and the dual-core PowerMac G5, which I will refer to as the “G5” from here on. The specifications of the two machines are as follows:
X2: Processor: AMD Athlon X2 4400+ @ 2.2 GHz Motherboard: DFI LanParty nForce4 Cache Memory: 1MB of full-speed on-die L2 per core System Memory: 2GB of CAS2 DDR-400 SDRAM Graphics Card: Gigabyte GeForce 6600GT 128MB Hard Drive: Seagate 7200.8 250GB SATA Optical Drive: MSI SATA CD-RW Power Supply: Seasonic S12 380W Case: Antec P180 Operating System: Ubuntu AMD64 5.10 G5: Processor: IBM PowerPC 970MP @ 2.3 GHz Motherboard: Apple Proprietary Cache Memory: 1MB of full-speed on-die L2 per core System Memory: 2.5GB of CAS4 DDR2-533 SDRAM Graphics Card: Apple GeForce 6600 256MB Hard Drive: Western Digital WD2500JS 250GB SATA Optical Drive: Pioneer DVD+RW Power Supply: Apple 600W Case: Apple PowerMac G5 Case Operating System: Mac OS X 10.4.3 Shared: Monitor: Dell 2405FPW LCD @ 1920x1200 Keyboard: Cherry Cymotion Xpress Mouse: Microsoft Intellimouse
In short, the two machines are very comparable in specifications. with the main differences being that the G5 has a DVD burner, while the X2 has the much faster “GT” version of the GeForce 6600 graphics card. It would seem that the G5 also has a much beefier power supply, but in reality, power supply ratings are about as reliable an indicator of performance as megahertz ratings, so no comparison can be made between the two without further testing.
From the outside, the PowerMac G5 is a beautiful machine. It is entirely aluminum, brushed to a gorgeous silver-white color. The perforated front contrasts nicely with the solid sides, and the white pulsing power light is a sophisticated accent. The machine is as solid, and heavy, as a rock. The side panels and handles are made of what appear to be 1/8″ aluminum plate. Anybody who knows aluminum knows that 1/8″ plate is serious stuff. It can easily support the weight of a man, and getting it to curve in the way the G5’s handles are curved requires a two-ton press. All in all, the G5 looks more like an expensive piece of audio equipment than a computer.
Unfortunately, the G5 doesn’t just like to be seen, but heard as well. The G5 is very loud compared to the X2. I somewhat expected the G5 to be louder, since I have optimized the X2 very intensively for silence, but it was louder than I expected. From an acoustic point of view, the G5’s noise issue are the result of a few critical failures in case design. The primary problem is the cooling system. It is very elaborate, with nine fans, a huge dense heatsink, and numerous air guides. It is entirely too much for a processor that supposedly has a thermal design power of 100W, and its overkill factor makes for a lot of unwanted noise. In comparison, the X2’s cooling system is built using a few simple principles of silent computer design. First, there are only three fans, and they are large, slow ones that move a lot of air at low speed. Noise is a 6th order function of air velocity, so making a fan twice as big but half as fast can result in a huge decrease in noise. Second, the X2 uses a large, but free-flowing heatsink. Turbulent airflow through a heatsink creates a lot of noise, and a constricted heatsink like the G5’s is noisier than a freer-flowing one like the X2’s.
A secondary problem is the case. The G5’s fancy aluminum case is an acoustic disaster. Plate aluminum is a very rigid, and thus very “loud” material. To compound the problem, there are few noise treatments on the inside of the case. Parts are mounted to the aluminum frame without isolation devices, ensuring that every slight vibration will be magnified into an audible annoyance. With nine fans and a noisy hard drive, there is plenty of vibration for the aluminum case to amplify. The X2’s P180 case, in comparison, is designed for silence. It uses a composite construction of plastic sheets sandwiched between aluminum ones. These panels dampen interior case noises instead of amplifying them. Inside the case, everything that can vibrate is mounted using soft silicone pads or grommets. These ensure that vibrating components are isolated from rigid structures, suppressing vibration noises.
A tertiary problem is the hard drive. It is a cheap Western Digital unit that is extremely loud. It can be heard while merely spinning, and when seeking it is distractingly audible. In comparison, the Seagate in the X2 is silent while spinning, and its seeks can barely be heard without listening carefully. In all, the G5 is barely tolerable from a noise perspective. Many people would find it adequate, even quiet, but gamers with 100 CFM Tornado fans don’t count, and I point to the popularity of silent computing websites as evidence of the fact that more and more computer users are becoming noise-conscious. One doesn’t even have to build their own computer to find a quieter machine than the G5. There are three Dell Dimension Pentium 4 machines in our apartment, and every single one is quieter by a large margin than the PowerMac.
Moving on to the inside of the machine, I would like to point out a few things about parts quality. There is an idea floating around that Apple somehow uses particularly high quality components. I find that idea to be a inaccurate. It is true that Apple uses a very high quality case, heatsink, and motherboard PCB, but that is about it. The hard drive in my PowerMac is, as I mentioned, a cheap Western Digital unit. If you type “250GB SATA” into Froogle, it is the unit that comes up at the very bottom of the price list. The fans are run-of-the-mill Delta pieces with audible bearing noise. The RAM is mix of generic and Crucial. I’ll leave it to the reader to guess which brand came with the machine, and which brand I added. The keyboard is light, mushy, and its keys do not spring back with conviction. The mouse is lightweight and has a very flimsy-feeling scroll nub. The X2’s components are superior in almost every regard, save perhaps for the motherboard and heatsink. The case is superior in the areas that matter, notably expandability and noise. It uses name-brand low-latency memory, a quiet Seagate hard drive, and a very efficient and quiet power supply from a company well-known, to silent computing folks, for the quality of their products. It uses fans that are $10 apiece, but worth every penny for their high-quality, silent bearings. It uses a keyboard heavy enough to wield in self-defense, with real German-engineered key switches that spring back as soon as pressure is released. It is, in short, a very high quality unit.
I have no problem with paying a premium for a premium product. I love my iPod, and think they are worth every penny, because their hardware really is superior to what is available in competing players. However, I cannot say the same for the PowerMac. Aside from the aforementioned case and cooling system, there is nothing in there that you wouldn’t find in a Dell.
Ultimately, it is not the case that you spend hours a day staring at, but rather what’s on the screen. In this regard, the PowerMac shows one of its best sides. From the stark grey boot logo to the network preferences panel, OS X presents a beautiful environment throughout. It cannot be stressed enough that the beauty of the environment is a function of many factors, of which the Aqua theme is actually only a small part. The most noticeable thing is the use of color. While OS X sticks to a palette of blues and grays, it occasionally uses splashes of reds, purples, and yellows to liven things up. Keeping an exciting interface like Aqua usable on a day-to-day basis is a challenge, but Apple accomplishes it by doing an excellent job of laying out interface elements. Even with the big icons and colorful widgets, nothing ever feels cramped or cluttered. Nothing ever seems like it clashes or is otherwise out of place. The attention to detail in this regard is astounding. For example, almost nowhere in the interface is there a small icon. Small icons are generally quite ugly, since they are hard to make out as anything but formless blotches of color. The only place they appear is in some window title bars. Interestingly, Apple seems to have removed them in the newer Platinum theme.
The menus are just incredible. OS X has the best menus, bar none, of any OS I have ever used. Apple seems to realize how important menus are in traditional computer interfaces, in a way few others do. OS X’s menus are big, uncluttered, and above all, clear and easy to read. They use big fonts, big arrows, big symbols denoting shortcut commands, and ample spacing between all the elements. Of course, OS X has the top menu bar which I love so dearly, and which, despite what some people think, works just fine on a large monitor. It also has the very-useful “application name” menu item, which contains the miscellaneous entries that always get scattered around randomly in other menu systems. Seriously, has the “exit” item ever made sense in the “File” menu? In all, OS X ‘s UI is a noticeable step up from GNOME’s, and a giant leap up from Windows’s. In comparison to GNOME, it is more colorful and artistic, but also a bit more busy. GNOME is more subdued and spartan, but lacks some of Aqua’s excitement. In this regard, personal preference plays a big role, and I can see many people preferring GNOME’s more laid-back style. Interestingly, I find GNOME quite a bit more rigorously consistent in look, but I find OS X’s slight variances in appearance to be more pleasing in day-to-day use.
Expose is great. I haven’t missed virtual desktops at all in OS X. My benchmark for window management is a long Matlab session. I’ve found that after a few hours of working in Matlab, I end up with a couple of dozen windows for simulation models, figures, graphs, m-files, etc. Windows absolutely chokes in this scenario, leaving me with a “Matlab” entry in the taskbar with a linear list of every open window. Of course, the list is full of completely non-descriptive names like “Figure 1”. Expose brings order to this chaos, and even allows me to switch to a text editor window to type up some results without completely messing up my workflow. Expose is a wonderful example of taking advantage of the natural strengths of human users, in this case image recognition, to solve a complicated interface problem.
Since I stare at text all day, I am quite picky about the quality of text in the interface. After living with it for a week, I have to say my feelings on OS X’s text are mixed. One one hand, I have to congratulate Apple for using nice, large fonts throughout the OS. Apple’s default UI font is Lucida Grande at 13 pt, equivalent to a Windows font size of about 10 point. It is a pleasure to look at compared to Microsoft’s microscopic 8 point Tahoma font. OS X’s renderer seems to use very light hinting, so the rendered glyphs retain most of the aesthetic qualities of the original font. In comparison, Window’s ClearType renderer contorts glyphs until they their original forms are unrecognizable. Now, on the other hand, OS X’s fonts are quite fuzzy compared to ClearType’s. Having first used anti-aliased fonts in BeOS, I have no problem with fuzzy fonts. My main requirement is that the rendering be sufficiently sharp to keep me from getting eye-strain at the end of the day, and OS X’s renderer meets that criterion adequately. I must say, however, that FreeType with auto-hinting is still my favorite renderer. It is in between OS X’s renderer and ClearType in both shape accuracy and sharpness, and to my eyes it is a happy medium.
One aspect of interfaces that often gets neglected is the tactile interfaces to the OS. Luckily, the tactile interface is something that Apple does not neglect. OS X’s keyboarding interface is excellent. While OS X is often considered to be an OS for new users, it is obvious that its keyboard shortcut mechanism is designed with power users in mind. The shortcuts are consistent, easy to reach, and thorough. The mousing interface is comparably good. Menus are very easily navigable, with hysteresis delays tuned to maximize the feel of control. It is in areas like these where Apple’s long background of hard UI research really shows through.
I do have a couple of gripes about the UI. First, file typing is a mess. It seems to me that an OS as otherwise elegant as OS X should use a more elegant method of file typing than file extensions. The situation would be better if OS X at least handled file extensions properly, but it doesn’t. It seems to use a weird mix of extensions and creator codes that results in completely unpredictable behavior. For example, I originally wrote this article in TextEdit. When I opened it up in Safari, it would open it as a plain text file, not an HTML page. I tried copying the file to another name via the CLI, but that didn’t work. However, when I opened up VIM in the terminal, and pasted in the text of the article from TextEdit, the resulting file opened up as HTML in Safari. At this point, I still have no idea what happened, I’ve just taken to editing HTML files with Emacs instead. I also find it difficult to determine when a file extension will automatically be provided and when I must type one. I really can’t stand that Finder, by default, shows some file extensions, like .pdf, and hides others, like .png. In comparison, GNOME handles file typing wonderfully. I’ve never been surprised by what file type was assigned to a file, and the way the GTK+ file dialog is set up, it is absolutely clear what the actual file name will be when the document is saved. Also, it’s nice how in GNOME naming a file with a particular extension will cause the application to save the file in the format associated with that extension. I tried to do this in OS X’s screenshot utility, but instead of saving the file to the format I wanted, it simply yelled at me and said that the extension must be “.tif”. My last gripe my seem minor, but it has been bothering me quite a bit. Safari’s “Show in Finder” icon in the Downloads window looks exactly like the Spotlight icon. It is completely non-obvious that the icon has anything to do with the Finder without reading the mouse-over text. Actually, the “magnifying glass” element in general is overused in OS X, since it’s part of the Sherlock and Preview icons as well.
Let me say this at the outset: software is the greatest strength of the Macintosh platform, and my primary motivation for buying the PowerMac. Between the high quality bundled applications and the wide array of available third party programs, the Mac has everything most desktop users will need. Since software is a rather personal matter, the best I can do here is to make some comments about the applications I use on a regular basis, and hope that the reader finds some overlap with his own usage patterns.
First, a meta-comment about how applications are handled on OS X. I’m on the fence about the DMG installation method. It is quite a bit more manual than APT on Ubuntu. I miss being able to update all my applications from a single interface. Further, since there is no way to install ancillary files along with a program, the documentation that accompanies the program in the DMG usually gets thrown away with the DMG. It is also irritating that there are several different ways of installing apps. Most use the DMG method, but Apple’s own apps use a PKG installer. On top of that, Fink uses its own APT-like system. However, application installation on OS X is better than the cumbersome underlying mechanisms would suggest. The biggest advantage of OS X is that its developer base can, and does, target a single version of the OS. Furthermore, because of the expectations of users, developers take the time to package their applications very nicely. The difference between the two platforms is mainly noticeable with obscure software that doesn’t normally get packaged by major distributions.
Okay, let’s get the Finder out of the way. The OS X Finder seems to engender love-it or hate-it reactions, and well, I’m in the latter camp. I don’t hate it, per-se, but I don’t like it very much either. I have to admit that using GNOME for the last six months has really made me a spatial junkie, and I really do not like going back to the browser paradigm. Also, the OS X Finder really is as unpredictable as everyone says it is. There is a weird mix of spatial remnants in with the browser style. For example, if you click on “Macintosh HD” when you have an existing Finder window open, it will open a new Finder window unless the existing one has “Macintosh HD” open. However, it doesn’t carry this exclusivity through the interface, since when you open another Finder window, you can browser to “Macintosh HD” in both. I could gripe about the Finder some more, but a far better reference for Finder’s issues would be John Siracusa’s articles about it at ArsTechnica.
On a happier note, let’s consider Spotlight. Spotlight is an enormous boon for a user like me who hates organizing files manually. It’s extremely handy, only a shortcut key away, very fast, and has an excellent success rate in finding relevant files. The fact that it searches file contents as well as file attributes puts it a step above the search implementation in BeOS’s BFS. Live search folders are as handy as they were in BeOS. I use them to organize my e-mail messages, which allows me to find e-mails from a particular professor, for example, just by opening a folder. I keep trying to find more uses for Spotlight as I go along, but I’m already very satisfied with its performance. Apple did an excellent job of integrating search into multiple places in the UI, such as the Finder, the file dialog, and the menu bar, making the feature much more useful than it would have been with just a single point of access. I really like how Apple integrated meta-data annotations into the UI. The file information window simply has a plain text field named “Spotlight Comments”. This simplicity makes a lot of sense. Given the users who will rely on Spotlight, the ones who don’t organize their files into neat directories, files aren’t likely to get detailed typed annotations. A simple free-form text field, however, has a hope of getting used.
Moving to the other much-ballyhooed OS X feature, Dashboard, I have to say that my reaction is: eh? I simply don’t find it particularly useful, at least in its present incarnation. I don’t need a computer to tell me that it’s cold outside on a November morning in Atlanta. I don’t need to look at the clock, because there is a nice digital watch right in the corner of the screen. I have never found a tedious on-screen calculator useful, preferring the real one on my real desk. I suppose Dashboard has potential, but as it is, it tells you either what you didn’t need to know, or what you already did.
Next, let’s consider Safari, OS X’s standard web browser. Safari is, in general, a decent browser. Its rendering quality is fairly good, though not as good as Firefox’s, and its integration into the overall environment is superb. Its interface is classically Apple, with a very minimal combo toolbar and address bar, and sparse yet eminently useful menus and context menus. It is configurable enough, and offers just enough features, like the integrated Google toolbar, to keep me from straying elsewhere. The RSS feeds feature, in particular, is very nice, and quite useful for those who like to keep up with Slashdot, OSNews, CNN, and other news sites. My biggest complaint with Safari is bugginess. Safari leaks like a sieve. I’ve been running it all day, and now with no windows open, it’s using 230MB of RAM. Its also unstable. In the week, Safari has crashed on me at least three times. Further there are occasional visual glitches, such as bits of horizontal scroll bars “sticking” to the content area during vertical scrolling. Finally, there is an infuriating bug which will cause the browser to sometimes go back several pages after hitting the back button just once. Whenever I try to get back to my GMail inbox after reading a message, I’m thrown back to whatever website I was browsing before. Normally, I’d be quite pissed off about a browser that has crashed three times in a week, given that Firefox was very stable, but given the instability of recent versions of Firefox, I’m willing to cut Apple some slack. I am, however, like most OS X users, waiting for 10.4.4.
I was originally going to have separate sections for iTunes, Mail, and iChat, but then I realized: who cares? iTunes plays music, Mail shows you your mail, and iChat lets your friends send you funny links. They all do their job just fine, and behave just like every other jukebox/e-mail client/AIM client in existence.
The OS X terminal is quite a bit better in its Tiger incarnation than it was in early versions of the OS. It has proper clipboard integration and acts as a drag-and-drop target for files. It features command completion, a command history and decent amount of flexibility with regards to terminal emulation. Its interface leaves something to be desired, however. It doesn’t anti-alias fonts by default, and figuring out how to enable the feature is non-intuitive. Terminal’s preferences menu doesn’t actually contain any preferences, those are in a separate “window settings” menu. Terminal’s biggest weakness is that it is glacially slow. I thought GNOME’s terminal was glacially slow, but OS X’s redefines glacially slow. Let’s just put it this way: one of my Lisp compilers has a warning in the documentation to not run the build from OS X’s terminal, because Terminal’s slow handling of the compilation messages actually slows down the build significantly!
Normally, I would consider a system preferences app too minor to include in a review, but OS X’s deserves some recognition. OS X’s preferences tool exposes a surprising amount of configurability, and has very good tools for network and firewall configuration. Certainly, it is more powerful than GNOME’s spartan configuration tool. However, it exposes its functionality without ever making the interface seem cluttered or hard to manage. Given its excellent organization, Spotlight integration seems a bit redundant, but it’s a nice touch. Overall, it’s a perfect example of how beautiful OS X applications can be. The slick Platinum title bar blends nicely into the main window. The layout is precise, and everything seems like it is in the proper place. The window changes size smoothly as required to contain the widgets within. Clearly, a great deal of attention went into making this overall excellent preferences application.
One of my favorite apps on OS X is TeXShop, a front-end to the TeX typesetting system. TeX is a markup language, like HTML, that is extremely powerful and well-suited to writing everything from scientific articles to novels. It is, in short, everything that Microsoft Word aspires to, but knows that it can never achieve. TeXShop is a sublime front-end to a number of different variants of TeX, notably LaTeX and ConTeXt. Its interface is simple and elegant, certainly deserving of the design award it won from Apple. At the same time, it exposes a great deal of power. It has large set of pre-built templates, for generating the code for things like tables and figures, a macro editor, and good AppleScript integration. It does tag completion, brackets-matching, and spell-checking. In all, if I was stuck on an island with a thesis to complete, TeXShop is the one application I would want to have with me.
Another app that I couldn’t live without on OS X is Aquamacs. Aquamacs is Emacs with a native Carbon GUI. Its integration with the OS is fairly good. It uses the standard top menu bar, but doesn’t have a native-looking preferences panel or have native context menus in the editor windows. However, it has excellent support for native OS X shortcut commands, which means that the app is completely usable without having to learn Emac’s horrid and user-hostile shortcut sequences. Aquamacs also integrates with an Emacs package called SLIME, which turns Emacs into a top-notch Lisp IDE. SLIME, in turn, integrates with an excellent Common Lisp system for OS X called OpenMCL, which features a fast, native-code compiler, good code generation, and great error messages. Similarly productive environments for Lisp development are available on other platforms, but the Aquamacs/SLIME/OpenMCL combo is the first one I’ve found that combines the significant virtues of running on a UNIX platform, integrating with the host GUI, and being free.
Aquamacs and SLIME
I hate to end things on a depressing note, but I need to say a few words about another application I use regularly, Matlab. Matlab, in its Mac incarnation, sucks. Of course, it sucks on every platform, so that is not too much of a complaint. Matlab is an X11 application, and very clearly clashes with the rest of the platform. It doesn’t use the top menu bar, preferring to it an in-window menu bar. Matlab is an eclectic mix of a main program using a custom toolkit, and add-on programs using Java’s Swing. The latter are rather buggy, and are brain-dead from an interface point of view, but are made tolerable by OS X’s good Java implementation. One thing Matlab brings out, through no fault of its own, is the uneasy truce between the CLI and GUI worlds in OS X. OS X’s GUI/CLI integration is not nearly as good as it was on BeOS. The UNIX filesystem looks quite different from the Mac one, and it is always confusing to use Matlab, which has a mixture of both by virtue of having its own file browser as well as using the standard OS X file dialogs. On the point of GUI/CLI integration, OS X is definitely inferior to GNOME on Linux.
Matlab and X11
OS X’s performance has always been contentious issue. I myself found early versions of the OS to be unusable, given the machines on which it was expected to run. Luckily, 2.3 GHz will light a fire under even the fattest software. In a week of usage, I never found the machine to be slow. It doesn’t feel super-fast, the way BeOS used to, but it never lags under load or otherwise freeze up. I was quite impressed about the speed of the OS X widget set. OS X’s widgets feel very fast and smooth. For example, Spotlight’s result list always scrolls and resizes smoothly, even when it is displaying hundreds of hits. Of course, another advantage of OS X’s graphics system is that redraw is always flicker-free, since the desktop is double-buffered. This feature lends an incredible feel of solidity to the desktop, one I find far preferable to Windows’ faster but “twitchier” behavior. The performance picture isn’t all rosy, however. Darwin really is slow, and it’s not just something a server administrator will notice. Basic things I do in the CLI, such as expanding large archives, feel much slower on the G5 than on the X2. Though I did not include compile performance in the benchmark results below, because compiling to PowerPC and to AMD64 are two different things, I found that the G5 is perhaps two-thirds as fast at compiling software as the X2. The blame for this issue can be distributed among the G5 CPU, for its mediocre integer performance, and Darwin, for its mediocre file I/O performance.
At this point, I would like to present some benchmarks I’ve conducted, but want to preface them with a warning. The benchmarks below are not designed too show off the G5 or the X2. They are not designed to show the absolute best performance achievable on each platform. The SPEC benchmarks, the results of which are easily available, do that very well. What these benchmarks are designed to do is to give an idea of what the machines will actually behave like running real software. Therefore, I didn’t use XLC on the G5 or Intel C++ on the X2. I used good old GCC 4.0.1, which is the standard compiler on both OS X 10.4 and Ubuntu 5.10, and is the one with which most applications on these two platforms will be compiled. I should also point out that the use of GCC gives an advantage to the X2, not so much because GCC optimizes better for x86, but because the Opteron architecture is much more forgiving of mediocre code generation. I consider this a fair arrangement, because the reliance on magic compiler technology for good performance is as much a design flaw as a crappy FPU or slow memory bus. In the world of SPEC, the processor has the privilege of running highly-tuned code. In the real world, it runs whatever the user wants to run, which, more often than not, will be mediocre code from a commodity compiler. I would also like to make a comment about benchmarking in general. I am not someone who is impressed by small constant factors. I consider differences of 5%, the kind that gamers get excited over, to be statistical noise. I do not think most people will even notice a difference of 10%. At 20%, the differences become noticeable, if one is looking, but I can’t say I’ve ever been in a situation where 10 minutes would have been too long, but 8 minutes would have been acceptable. From my perspective, unless I’m trying to show off, the difference has to be in the 30% range before it matters.
The benchmark lineup below is designed to reflect the type of programs I use on my machines. I use my computer for web browsing, listening to music, writing code, writing reports, and running engineering software and simulations. As I mentioned earlier, all the benchmarks were conducted using GCC 4.0.1. In the case of the G5, it was the version in XCode 2.2, while for the X2 it was the default version in Ubuntu 5.10. The compiler options used were as follows:
G5: -O3 -mcpu=G5 -mtune=G5 -mpowerpc64 -mpowerpc-gpopt -funroll-loops X2: -O3 -march=k8 -funroll-loops
The X2 doesn’t really care about the compiler flags, but the G5 does. Using the above flags improved the performance of the G5 noticeably compared to the “-O2” option I normally use. It should also be noted that I didn’t use Apple’s ‘-fast’ metaflag, for a number reasons. First, it is partially redundant. It specifies several statements that are on by default anyway. Second, it slowed down benchmarks, relative to the above flags, as often as it sped them up. Third, on the one case where it did show noticeable improvements over the above flags, nbench, it also generated code that could not complete the Neural Net portion of the test. The problem flag in question, -ftree-loop-linear, caused Neural Net to hang on both the G5 and X2. At this point, an astute reader will notice that, using the aforementioned compilers and compile flags, the following benchmarks were run in 32-bit mode on the G5, and 64-bit mode on the X2. This difference was intentional. The G5 is fastest when running 32-bit code, and the X2 is fastest when running 64-bit code. Moreover, OS X and its apps are almost completely 32-bit, while Ubuntu and its apps are almost completely 64-bit. Not only was each processor running in its fastest mode, but each was running the type of code it would run during normal usage.
One last note before getting to the benchmarks. Each benchmark description specifies the units in which the result are expressed, as well as whether higher or lower values are better. Listed along with each result is a ratio specifying the relative performance of the G5 to the X2. Regardless of the unit of the benchmark, “ratio” values over 1.0 mean the G5 was faster, while “ratio” values below 1.0 mean it was slower.
The first benchmark is a test of MP3 encoding performance using LAME. This benchmark should test the processor’s integer performance on large streaming data sets. The version of LAME used was 3.96.1. The source data was Live’s “Birds of Pray” CD, ripped by iTunes to WAV format. The results below are the time, in seconds, taken to encode the entire CD. Lower values are better, and are the average of three trials is reported.
G5 X2 Ratio LAME: 4m41s 4m51s 1.04
This particular benchmark is a good showing for the G5. For all intents and purposes, the two processors achieved the same result. Now, the G5 should have achieved a slightly higher result, given its significantly greater memory bandwidth, which indicates that its integer performance is weaker than the X2’s.
The next benchmark is TSCP, a chess AI. This test should be a good indicator of the system’s performance on branch-heavy integer code, such as many AIs and other forms of decision logic. The version of TSCP used was 1.81. The results below are in thousands of decision nodes visited per second, with higher values being better and the average of three trials being reported.
G5 X2 Ratio tscp: 303.3 388.7 0.78
This result shows what happens to the G5’s long 16-stage pipeline when many branch mispredictions occur. Like the Pentium 4, it suffers a significant penalty on such types of code.
The next benchmark consists of a pair of neural network simulations. Please see the benchmark’s site for a description of the kernels. The results below are in seconds required to complete each test, with lower values being better and the average of three trials being reported.
G5 X2 Ratio BPN: 5.16s 5.63s 1.09 SOM: 1.34s 1.42s 1.06
Interestingly enough, the G5 beats the X2 in this integer benchmark. The reason appears to be a combination of several factors. First, while this benchmark is integer-heavy, it has very few branches and consists mainly of a large number of memory accesses to multi-dimensional arrays. Since these arrays fit in cache, the G5’s slightly lower-latency L2 and 5% clock-speed advantage allow it to edge out the X2.
The next benchmark is typesetting a large TeX file using pdfeTeX. This benchmark is a purely integer benchmark that tests the processor’s performance in manipulating tree-like data in cache. The specific TeX program used was pdfeTeX version 3.141592. The results below are the time taken to produce a PDF from the source file, in seconds. Lower values are better, and the average of three trials is reported.
G5 X2 Ratio physics.tex: 1.241s 0.950s 0.77
These results are consistent with what we saw regarding the G5’s integer performance in the tscp benchmark. It should be noted that the source file was small enough to fit into cache. Had the source data been large enough to spill into memory, the results for the G5 would likely be a bit worse, given the random memory access patterns involved in the benchmark and what we can see of the G5’s memory performance in the later benchmarks.
The next benchmark is SciMark2. Two variants of the benchmark were used, one with a small data set and another with a large data set. Note, I do not report the composite score, because it makes no more sense to me to sum the results of completely different benchmark kernels than it does to sum vectors and kumquats. Please see the SciMark FAQ to see what each test kernel does, and then compare each result individually. The results below are in MegaFLOPs, with higher values being better, and the average of three trails being reported.
G5 X2 Ratio Small FFT: 583.4 585.3 1.00 Large FFT: 32.0 56.0 0.57 Small SOR: 434.0 515.2 0.84 Large SOR: 394.1 505.9 0.78 Small MC: 86.3 261.9 0.33 Large MC: 86.6 260.6 0.33 Small SMM: 744.7 722.2 1.03 Large SMM: 312.2 351.9 0.89 Small LU: 1202.9 837.6 1.44 Large LU: 411.5 424.6 0.97
Well, these results are all over the map. The most noticeable thing is that the X2’s performance degrades much more gracefully when we go from the small, in-cache data set to the large, in-memory data set. Clearly, the X2’s low-latency memory subsystem gives it a leg-up in these benchmarks. Even with 33% more memory bandwidth and 5% more clock speed, the G5 loses in nearly every test. In most of these cases, the G5 is 80% to 90% as fast as the X2, and is 44% faster in one case, but in three of the benchmarks, it is about one-half to one-third as fast. Poor code generation by GCC on a couple of these kernels is a likely explanation.
The next benchmark is a C version of the classic LINKPACK benchmark. LINKPACK is an extremely simplistic benchmark that measures the raw FP throughput of the processor by doing large matrix multiplications. It represents the best case for FPU performance on a particular processor. The variant below is a double-precision version of LINPACK. The results below are in MegaFLOPs, with higher values being better and the average of three trials being reported.
G5 X2 Ratio LINPACK: 1391 876 1.59
The results of this benchmark are great for the G5. It is well over 60% faster than the X2 in this benchmark. This result is to be expected, since the G5 has a floating-point multiply-accumulate (FMAC) instruction, which is an important part of the matrix multiplication algorithm. On the X2, the compiler must generate two separate instructions to have the same effect as one FMAC.
The next benchmark is a Fourier transform, specifically the one distributed with the FFTW 3.0.1 source code. Four variants were used here, a small and large double-precision FFT, and a small and large single-precision FFT. All are in-place, complex, forward transforms. In this benchmark the small data-set result is more important. I don’t know of any particular uses for 1 million point FFTs, though I’m sure there are some. In comparison, 4096-point FFTs are quite common in signal processing, and JPEG2000 uses a related algorithm on similarly sized blocks for image compression. Since AltiVec cannot do double-precision math, both AltiVec and SSE2 were disabled for the double-precision tests. For the single-precision tests, AltiVec is enabled, but for some reason FFTW generates improper assembly for SSE2 (on GCC 4.0), so in fairness no numbers are reported for the X2’s. However, the G5 results are reported anyway, because they show that the G5 makes one heck of a digital signal processor! Moreover, these results are likely quite representative of highly-tuned AltiVec-friendly algorithms. As before, the results below are in MegaFLOPs, with higher values being better and the average of three trials being reported.
G5 X2 Ratio Double (4K): 2594 2044 1.27 Double (1M): 777 662 1.17 Float (4K): 3709 * * Float (1M): 915 * *
These results support my belief that GCC generated poor code on the G5 for the FFT in SciMark. The G5 wins by a quite a margin in both cases, even though we can again see the X2 closing the gap when memory performance comes into play.
The next benchmark is raytracing with POVray, using the built-in POVray benchmark. This benchmark tests the performance of the CPU on an essentially floating-point algorithm with a significant integer component. Random access memory performance also comes into play for accessing many of the bookkeeping data structures necessary to perform the actual raytracing step. The version of POVray used was 3.6.1. The results below report the time required to render the 384×384 test image. Lower values are better, and the average of three trials is reported.
G5 X2 Ratio POVray: 32m32s 25m31s 0.78
We see here that despite its very impressive theoretical floating-point performance, the G5’s integer performance hurts it in this real-world application. While some would argue that POVray isn’t optimized for the G5, it should be noted that POVray isn’t exactly optimized for the X2 either. Although, I think it is safe to say that the G5 has more untapped potential in situations like these than does the X2.
The next benchmark is a Blender render using the pseudo-standard Blender benchmark file test.blend. A word of warning about this benchmark. I could not get it to compile properly on OS X with GCC 4.0. As a result, I used the standard binary for OS X. I do not consider these results fully representative of what the G5 can do, but have included them anyway, because in the real world, it is rarely the case that all of one’s applications will be using the vendor’s absolute-latest compiler. This test stresses a number of different aspects of the system, since rendering involves both floating-point and integer operations on large in-memory data sets. This test should be a good indicator of how the G5 can be expected to run media applications not specifically optimized for a particular processor. Note that this test is dual-threaded, so it uses both cores on each CPU. The results below are in seconds, with smaller values being better and the average of three trails being reported.
G5 X2 Ratio test.blend: 1m34s 1m15s 0.80
These results are about as expected, and very similar to the POVray result above.
Moving on to the mixed-code benchmarks, we have FreeBench, a free cross-platform benchmark suite. The version used was 1.0.3, compiled from the UNIX tarball for both machines. Some scripts were edited on OS X to make the suite build properly, but no code was changed. A description of the test kernels can be found here. The results below are speedup relative to a 333MHz Sun Ultra 10, with higher values being better and the average of three trails being reported.
G5 X2 Ratio Analyzer: 7.71 3.28 2.35 4 in a Row: 12.01 16.97 0.71 Mason: 8.76 11.42 0.76 pCompress2: 6.59 9.68 0.68 PiFFT: 5.72 6.71 0.85 DistRay: 7.59 8.88 0.85 Neural: 3.56 7.89 0.45
Aside from the two outlying values, these results are fairly consistent with what we’ve seen so far. The G5 performs around 75% as well as the X2 on integer code, and 85% as well on general floating-point code.
The last benchmark is nbench, which is a total processor benchmark based on the original ByteMark. The version of nbench used was 2.2.2. Again, I think combining the results into a composite score is meaningless, so I do not report the final average. Please read the description of each kernel here and evaluate each result individually with consideration to what performance parameters are tested by each kernel. The results below are speedup relative to a K6-233, higher values are better, and only one test was run since nbench has its own trial-repetition and averaging logic.
G5 X2 Ratio Numeric Sort: 7.19 9.43 0.76 String Sort: 25.28 13.92 1.82 Bitfield: 7.03 11.97 0.59 FP Emulation: 17.42 16.88 1.03 Fourier: 17.14 12.79 1.34 Assignment: 26.18 35.59 0.74 IDEA: 19.18 24.08 0.79 Huffman: 12.48 14.71 0.85 Neural Net: 2.03 28.10 0.07 LU Decomp: 34.59 45.43 0.76
All in all, this benchmark is a decent showing for the G5. It loses two benchmarks by a large margin, wins two by a large margin, ties one benchmark, and is between 75% and 85% as fast as the X2 on the rest. The neural net result is incredibly bad, but that is partly the result of compiler optimizations. When using “-Os”, the G5 achieves a score of around 14 on this trial, though it scores in all the other kernels suffer significantly.
The above benchmarks present a lot of numbers to go through. However, a few trends clearly present themselves. For general integer code, the G5 shows itself to be about 75% as fast as the X2. For general floating point code, it seems to be 85% as fast. For code that really works to its strengths, it can be up to 50% or more faster. Of course, on code that really hits its weaknesses, or hits bad compiler optimizations, as may be the case, it can be 50% or more slower. Some observations we can make are that the G5 seems to be quite picky about code generation, given the many cases above where its performance drops to a fraction of that of the X2. We can also see that its memory controller is relatively poor compared to the X2’s, since its performance drop in the large data tests is always larger than X2’s performance drop. The G5 seems to have an excellent FPU, which shines in some particularly suitable benchmarks but is more often than not hampered by its mediocre integer performance and memory subsystem.
Let me address the inevitable “Ubuntu vs. OS X” comparison. The thing that surprised me most about using the PowerMac was not that OS X’s UI was better than Ubuntu’s, which I have known for quite some time having used both regularly, but how small that difference really was. As I said, OS X’s UI is a step up from GNOME’s. However, I wouldn’t say it is in a completely different league. In terms of the fundamental UI elements, GNOME is extremely competitive. In some areas, file type management as I noted above, GNOME is better, largely because it is more rigorously consistent. On the other hand, OS X’s interface is faster, sexier, and a touch more polished, which is icing on the cake. In terms of ease of configuration and maintainability, both machines were comparable, which is expected given that each machine was purposefully built to work with its respective OS. Lastly, Linux, as a kernel, is miles ahead of Darwin. Ultimately, if it were just a matter of “Ubuntu versus OS X”, I’d see little reason to keep the PowerMac. What really makes the Mac shine are its applications. Even commonly-used OSS programs, like VLC, are better in their OS X incarnation. Add to that the software you can only get on OS X, TexShop and Aquamacs in my case, then there is a compelling argument for OS X.
The Value Judgement
I would like to, for a moment, address the issue of value. The question is: is the PowerMac worth it? This is a complex question, with subjective elements, but there is no reason that it cannot lend itself to analysis. The PowerMac, as configured, would cost $2700 retail, if the added RAM were bought from a third party. The X2 cost $1700, and factoring in a hefty profit margin of 20%, what Apple makes on its high-end machines, would sell as a $2000 retail machine. The price difference comes to $700, just a bit below the average retail selling price of desktop computers. For the extra $700, the PowerMac is slower, louder, uses cheaper parts, and runs OS X. The mathematics of the situation are clear. If OS X is worth an extra $700 plus performance and silence to the buyer, the PowerMac is a good value. Since the PowerMac is staying by my desk, it’s obvious what OS X and the software that runs on it is worth to me. However, to very many people, OS X and its applications will not be worth that much.
I would also like to address “The Switch”. The way I see it, switching was a very good thing, for multiple reasons. From a performance standpoint, the 970MP is not the savior of PowerPC on the desktop. It is, simply, too little, too late. A gross generalization of the above benchmarks would peg the G5, when running code not specially optimized for it, at about 85% the performance of the X2. As I said before, I consider this insignificant. However, let’s look at it from a marketing perspective. 85% of the X2 4400+ puts the mid-range 970MP squarely below the lowest-end Athlon X2, the 2.0 GHz 3800+. That’s not a good thing when the chip is in a machine that costs more than its competitors’ high end ones. There is, of course, the issue of the upcoming PA Semi PowerPC chip. In my opinion, the PA Semi chip represents precisely what screwed PowerPC on the desktop to begin with. It is an embedded chip, and we all know how great it was for Apple to rely on an embedded chipmaker to supply their desktop processors. Furthermore, it’s performance is lackluster compared to today’s machines, much less the machines of 2007 with which it will compete. It’s SPECFp is good, about as high as the best Opteron’s, but its SPECint is at the level of the slowest Opterons available. The PPC970 and the Pentium 4 should have been a lesson to people that a chip with great floating-point performance and mediocre integer performance is not going to fly with developers. This is especially true considering that FPU performance is becoming less important with the advent of GPUs and GPU-enabled media libraries like CoreImage. PowerPC-lovers need to look hard at the Opteron and see why the market has embraced it so well. The Opteron is not the leader in any one category. However, it is an extremely well-balanced chip that shows great performance in a large variety of problem domains. It doesn’t need great compiler technology to perform well, and it doesn’t choke on particular types of code. It has a decent price, decent power usage, and is nicely scalable. It is, in short, everything that the PPC970 isn’t, that the Cell isn’t, and what Intel is hoping Conroe and Merom will be.
The Last Word
The PowerMac G5 is a frustrating machine. As a piece of hardware, it is inferior in almost every way to the Athlon X2 machine sitting next to it. That is not to say that it is a bad piece of hardware, but rather that it can’t match up to a very excellent machine. However, software is what counts and OS X is the platform that runs the applications I want to run. For that reason alone, the PowerMac isn’t going anywhere any time soon.
About the Author
Rayiner Hashem is a student of aerospace engineering at the Georgia Institute of Technology. His interests in the field of computing include operating systems, programming languages, and compiler technology.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.