IMG: Apple’s released their newest computers, the G5’s – I’ve ordered my dual. Apple says I’m getting it in October – can’t wait! Apart from the obvious boost that comes with an increase in megahertz, bus speed, and DDR RAM, am I going to see speed improvements in my games?
Brad: From what I can tell, definitely. The biggest win for gamers (IMHO) will be the massive memory bandwith that the G5 can provide. If you chew through tons of data (as a lot of games do), then the new G5 boxes will help greatly. At WWDC we saw some great performance out of the dual G5 boxes on the games we brought to test. I don't have any numbers handy, unfortunately.
IMG: I’m assuming that, as is the case with multi-threaded applications, special code will need to be written for programs to take advantage of the G5’s 64-bit architecture. Is that something that programmers will automatically include in game code as they port the game, or is that up to the software publishers to determine whether or not to add G5 support?
Brad: It'll really depend. The main benefit from having a 64-bit architecture comes when you need to move around and access large amounts of memory. And by large, I mean much larger than most games today need. So I think it'll be a while before we see a need to include 64-bit code in the games themselves. I'm told that the OS that ships on these boxes includes 64-bit optimized routines for essential stuff, like the system calls for moving memory around, allocating memory and the like. Beyond that, I'm hard-pressed to think of a way to enhance an existing game with special 64-bit code.
IMG: That makes sense, especially since most of the games published for the Mac come from Windows, which is still a 32-bit OS. Would CodeWarrior or any of the other development tools add G5 optimization as part of their compiling routines?
Brad: gcc (used in XCode and Project Builder) has pretty good G5 support from what I've read. It'll schedule instructions for best performance on a G5. I asked Metrowerks about CodeWarrior and G5 support, and they currently don't have a timeline for G5 support (or even if they'll charge for it or provide a free update), so it seems like they're behind the curve a bit.
IMG: It was revealed a few weeks ago that Microsoft’s Virtual PC won’t run on Apple’s new machines because the G5 chip doesn’t contain support for one of the software calls, the “pseudo little-endian mode”. Do you see that causing any problems with any of the games our on the market, or games that you are currently working on?
Brad: Nope, not at all. The PowerPC chips normally run in "big endian" mode, but you could force them to run in "little endian" mode, just like Intel-based PCs. That's a pretty impractical feature for games, but it has it's benefits if you're running an x86 emulator. :-)
IMG: Apart from little endian mode, are you aware of any other software calls that may or may not be supported by the new processors? Is this a non-issue?
Brad: There are some calls that cause performance hits or simply don't exist, but they're not particularly common and shouldn't affect game ports.
IMG: In terms of software routines, the following tech words were dropped by Duane Johnson in a recent video interview, but no explanations were given for what the hell they were talking about. Can you quickly explain what these optimization terms mean in layman's words?
“Data Structure Alignment"
Brad: In general, the PowerPC needs data to be aligned on 16-byte boundaries for maximum performance. Altivec in particular requires it. With the G5, some things now need to be aligned on 32-byte boundaries for maximum performance. Apple's Shark tool will highlight these on running code, so that's nice.
Brad: It's the act of converting a floating point number to an integer and vice-versa. This has always been a performance hit on PowerPC hardware. The G5 has some additional issues that cause this to be a larger problem than before. There's no way to avoid the performance hit in most cases, but we try to catch cases where an accidental float->int->float conversion happens - those can and should be avoided.
"Square Root Operations"
Brad: There's a PowerPC intrinsic instruction that does square root calculations. We usually use it instead of calling sqrt() since it's so much faster and in most cases as precise.