Don't ignore Altivec in this test
One thing which seems to have been missed in the discussion is that the problem being solved runs 10-13X faster when using code which accesses the Altivec unit. The P4 was not tested using this version of the code because the P4 is missing an Altivec unit.
One way to interpret these results, therefore, is: the G5 is the fastest computer for solving this problem, and only the G4 machines (with Altivec) were close.
Early posters seemed discouraged by these results, but I found them very encouraging, given that the G5 has very specific compiler requirements that couldn't be met when the Jet3D program was compiled. Presumably the test could be run again using IBM's recently released xlf compiler. There is reason to believe that very significant (40%) speed improvements may be forthcoming with a more G5-aware OS X (Panther), so stacking these two things together, it's quite likely that rerunning this simulation with xlf and Panther would demonstrate the G5's superiority vs. the P4 (without using Altivec...when using Altivec, it already isn't close) at higher GHz (3.2+?).
Benchmarking the G5 on code that doesn't utilize the VMX unit is really very misleading, as far as expectations of real world performance are concerned. Code that runs on the G5 *will* be written to use Altivec/VMX in the real world, and "testing" the G5 while the VMX unit lays idle can't be a good real-world test. It would be like benchmarking a Pentium on Mandelbrot fractals without compiling any code for the FPU--this would be very misleading. A benchmark which ignores large parts of a processor's real abilities is never a good benchmark, and this is part of my complaint about running the SPEC code to test machines that have vector processing units. The SPEC code ignores the VMX/Altivec units, a situation which no well-written real world code would ever do, and SPEC is therefore a very poor benchmark for processors like the G4 and G5 which have outstanding vector processing units.
All benchmarks need to be read with a grain of salt and a lot of knowledge. Without the grain of salt and only a little knowledge, benchmarking can be more dangerous than useful.