First, thanks to everyone who took the time to read parts one, two and three of my “mini series” this week. The discussion around the articles was very interesting, and some good questions were asked. Today I bumped the RAM in the mini to 2GB (after a brief wrong turn ), so I thought I’d take a few minutes to revisit some of the tests that may have been RAM dependent. I also tried to address the one major area my original report didn’t touch on—how well do things like printers and scanners work, as well as looking at a couple of other games.
The first thing I thought I’d look at was the application launch times test. I suspected that, particularly for the larger apps, the limited RAM available might be causing some issues. For both Photoshop CS2 and Keynote, the two largest apps I originally tested, I saw dramatic improvements in initial launch times (second launches were basically identical).
Beyond the big apps, though, I also saw small improvements in initial launch times for all the other programs. These differences were’t large enough, however, to be relevant given the hand timing I was doing.
ROB’S LAUNCH TESTS – REVISITED
|512MB Mac mini||2GB Mac mini|
|1st launch||1st launch||% Change|
Rosetta applications in italics.
Word document scrolling
I opened the same test document as before and scrolled from top to bottom. This time, the process took 21 seconds instead of 23, which is technically a 10 percent improvement. However, given I was hand-timing this test as well, I don’t feel it’s significant, so I’m calling scrolling speed “unchanged.”
Folder opening test
The results here really surprised me. With more RAM, the mini was much more adept at opening 200 folders at once. On the 512MB machine, this took 50 seconds. With 2GB installed, that time plummeted to only 28 seconds, which is actually quicker than the Dual G5. It took 17 seconds to close all 200 folders, also down dramatically from the original 50 seconds (though still slower than the G5). I had thought my results in this test were limited by the RAM available for the video card, but that doesn’t seem to be the case.
Other revisited topics
For the fun of it, I again tried to play two HD clips at once. Still no go; QuickTime bailed just as it did before. I also tried Front Row’s movie trailers feature, and still received the ‘movie trailer server is not responding’ message.
The big difference, obviously, is how the machine works with a number of apps open. The difference is dramatic, since there’s no virtual memory being used. I opened 10 applications at once, which took about 13 seconds total (that was impressive all by itself), and then worked in each of them, switching rapidly back and forth. Activity Monitor showed 1GB of inactive RAM along with 410MB of completely free RAM…and no page outs! You can never have too much RAM.
Someone asked how well MacMAME works. Based on some longer testing tonight, it seems to work just fine. The software renderer is notably quicker than the OpenGL option, and the games looked fine that way to me. It is, however, playable using OpenGL mode, but things seem just a bit slower. In software render mode, though, I noticed no such slowdowns; everything worked perfectly.
Someone else asked about Wolfenstein:Enemey Territory. I got the game loaded and moved around an empty map for a bit. I was seeing frame rates below 20, even with nothing on the map, at 1024×768. I suspect that, with a number of people onscreen at once, the game will become unplayable. A Universal version may solve that problem, but I have no idea who, if anyone, would be working on such a thing.
Finally, a bit of a treat. Jedi Knight II (JK2) was another fave game of mine from the past, and as it turns out, there’s a Universal patch in the works. Through Macworld’s Peter Cohen, I was able to get a beta build for some basic comparison testing. The results were impressive, and I’ve been given the OK to share some basic results.
JK2 includes a built-in benchmarking tool; this page at Inside Mac Games explains how to set it up, as it’s far from obvious. I ran the benchmark on all three machines, at 1024×768 resolution with the default settings for all the other options, and EAX audio disabled. First, the non-Universal results:
Even in Rosetta mode, JK2 runs quite well, scoring an average of 30fps. With that result, however, comes a caveat. I also recorded 30fps when testing in Rosetta at 800×600 and 640×480, which makes no sense whatsoever. All three results were identical, at 30.1fps. That’s just not realistic, and seems to imply there’s some sort of limiter in Rosetta for the OpenGL framerate (which also makes no sense). The JK2 programmer is inquiring with Apple about these odd results. Since both binaries use the same set of prefs, there’s no way some in-game setting was responsible for this limit, otherwise the Universal version would have been similarly capped.
In actual gameplay, large firefights can slow Rosetta JK2 down to the 15fps or so range, making things just a bit tricky, but still playable. Then I installed the beta Universal build, and re-ran the benchmark. This time, JK2 scored a whopping 90fps . Wow. Even when I cranked JK2 up to 1280×1024, I still got a very respectable 67fps out of the benchmark. In gameplay at 1280×1024, everything was smooth, with the instantaneous framerate display varying between 45fps and 90+fps. This is good stuff; I’m now actually working my way through JK2 again on the mini to see how it holds up as the game progresses.
Please keep in mind I’m using an unreleased beta build, so these figures are far from official, but I think people will be thrilled with this Universal version when it’s released.
Despite the length of the original piece, I somehow managed to completely overlook the topic of how well things like printers and scanners might work with the Intel Macs. I tested gaming peripherals, but not everyday usage peripherals. So tonight, I plugged in my key peripherals to see how they fared.
FireWire: Someone inquired about FireWire drive performance, so I tested it on all three Macs. I have both a portable 80GB (4200RPM) FireWire drive that I use when travelling, and a larger powered 200GB (7200RPM) drive that I use for key backups on the G5. I hooked each drive up to each machine, and then timed the copy of a 1GB folder containing 562 files to and from the FireWire drive. Since there are two drives in the G5, I tested with both of them. The results were basically as expected, with a notable exception:
|80GB FW||80GB FW||200GB FW||200GB FW|
|Copy to FW drive||Copy from FW drive||Copy to FW drive||Copy from FW drive|
|Dual G5 #1||47||37||41||33|
|Dual G5 #2||51||37||41||33|
BEST RESULTS IN BOLD.
With the slow portable drive, the results were similar for all three machines, since the portable drive’s speed was the limiting factor. As you can see, the mini did just fine in comparison to the other machines. With the faster drive, the G5’s faster drive let it move quicker, with the notable exception of copying from the G5 to the FireWire drive, where it basically tied the mini. (Also as noted elsewhere in my mini writeup, there’s something about my Dual G5’s hard drive performance that seems out of line. Investigating that issue is a project for next week.)
Overall, FireWire performance seemed right in line with what I would have expected.
Printers: I have two printers, an Ethernet-connected Brother HL-1270N and a USB-connected Epson Stylus Photo 890. Both worked exactly as expected, in both Rosetta and Universal applications. The Brother prints via a CUPS driver, and setting it up was identical to the process on my PowerPC Macs. The Epson was noticed immediately when I connected the USB cable, and no manual setup was necessasry. In short, printing support seems perfect, at least with my small sample size of two.
Scanners: I have an Epson Perfection 1660 Photo, and I tried two different methods of using it on the mini. First, I just plugged it in and then fired up VueScan, my scanner software of choice. It worked perfectly. Then, just for kicks, I headed over to Epson’s site, where I was surprised to find they have a Universal driver available. After installation, the buttons on the front of the scanner worked to start a scan, and the Epson Scan software seemed to work just fine. The only limitation on the Universal drivers is that they don’t presently support USB2. I’m not sure, but I imagine VueScan does, since it’s just communicating natively over the USB cable (that’s a guess, though, as I have no empirical evidence to support it).
Tablets: Now for the real surprise of my testing. I plugged in my Wacom Intuos 2 graphics tablet, and as expected, it didn’t do much more than work as a mouse. I went to Wacom’s site, and there was no mention of a Universal driver. So I downloaded the latest one I could find, 4.9.4, and installed that. I was actually surprised it installed, but it did. I was even more surprised when I was able to do this:
Yep, it worked perfectly. As seen in the screenshot, the sketchpad worked fine, including the pressure sensitivity. When I enabled handwriting recognition, I was again surprised—it worked great in not only Universal apps like TextEdit and BBEdit, but also in Rosetta apps such as Word and Excel. However Rosetta works, it obviously works at a fairly low level, as it seems to interact just fine with system-provided services such as handwriting recognition.
More RAM definitely makes using the mini more enjoyable, and more like the experience I have on the G5. I don’t think 2GB is required, by any means, but 1GB should probably be considered a starting point.
Although limited in scope, I think my little experiment with peripherals shows that the Rosetta to Universal transition may not be nearly as complex as was the Classic to OS X transition. My FireWire drives, printer, scanner, and even the drawing tablet all worked perfectly well on the Intel mini. Even better, no special trickery was required to make everything work. It either worked automatically, or worked after installing a driver package. Very impressive. The combination of Rosetta and the Intel mini seems to work quite well, from the application level all the way down to the hardware level.