In typical usage scenarios, the Non-8131 G5 with the UAD-1 rocks.
It seems the most common question I hear about the G5 is, "So how may instances can I get?" Well, it depends. To illustrate this, I set up a simple 24-track Logic session at a 24-bit/44.1k sample rate (all audio tracks--no automation or virtual instruments) and pulled it up on three different test systems. All three systems were running OS 10.4.1, Logic 7.1, UAD-1 V. 3.9 with an RME Fireface 800 doing the I/O duties. The individual Macs were a Dual 867 (Mirror Door) G4 (a non-8131 Mac as are all G4s), a first-generation Dual 2.0 "8131" G5 (uses the AMD-8131 PCI-X controller), and an April 2005 Dual 2.0 PCI "Non-8131" G5. The G4 had 768 MB of RAM, and both G5s had 1 GB. For the sake of comparison, I've included two PC systems in the chart. The first is an average AMD-based system (which has been the basis for our previous PC instance counts), and the second is a optimal system set up by our VP of engineering, Joe Bryan. These comprise the "PC range" column. All of these are nominal instance counts; as always, your mileage may vary.
So now let me put all of these numbers into context.
Using the counts from the non-8131 Macs as a benchmark, we can see that even the 8131 G5 (8131 Mac range in table) instance counts are not that bad. However, the important thing to note is that in cases where the plug-in counts were limited by PCI bandwidth (AMD-8131; numbers are in parenthesis), these instance counts may not get higher if you were to add additional UAD-1 cards. Where you will see the benefit of a second, third or fourth card is with the plug-ins that are not being limited in this way (i.e. limited by DSP load, not by PCI bandwidth). Also noteworthy is that the 8131 G5s require AMD-8131 mode to be enabled in the UAD-1 Meter, which adds extra host load per plug-in. So, if you had lots of virtual instruments and were already showing a high host CPU load on an 8131 G5, you also may not be able to get high instance counts.
Now if you look to the non-8131 Mac range instance counts, you will see that in every case I was limited only by available UAD-1 resources. Unlike in the 8131 G5s, adding a second, third or fourth card in these models will increase your plug-in counts. Also, you don't have to have the AMD-8131 mode enabled in the UAD-1 Meter, which means you don't have any extra host load per UAD-1 plug-in, freeing it up for all those CPU-hungry virtual instruments. Note that the AMD-8131 setting in the Meter is set automatically the first time you run the Meter or a plug-in; your specific hardware configuration is examined, and if there is a mismatch between the current setting and your particular hardware, the setting is changed to match, and you will be notified of this change via a dialog.
One interesting data point we found in conducting these tests the instance counts on the Non-8131 G5 are a little lower than the G4 in some cases. It turns out that, due to PCI implementation differences, UAD-1 DMA transfers are just slightly more efficient on the G4. This difference is most obvious in sessions where you have upwards of 20-plus small plug-ins. In typical scenarios where you are using fewer higher-DSP-load plug-ins, the results are pretty much the same as with the G4. Also, to put this G4/Non-8131 G5 comparison into perspective, the G4 was having a bit of a hard time handling the test session and all the commands and plug-ins I was throwing at it; the Non-8131 G5 handled it all with ease. If I were to have a pretty CPU-heavy session (lots of virtual instruments and/or automation), the G4 might slow to a crawl with some of those numbers, or get numbers lower than I got on the G5, which always had plenty of CPU to spare. In other words, in typical usage scenarios, the Non-8131 G5 with the UAD-1 rocks.
So all that being said, here's the bottom line:
On a final note, if you are looking for a new audio interface, I highly suggest the RME Fireface 800, which is what I used to do these tests with the Macs. (And no, you do not need FW800 for it to perform exceptionally well.)