[Gummi Bear]

I've seen the G5 benchmarks verus the Pentium 4
but i haven't seen the G5 v. G4's

does anyone have the benchmarks on these?

[Xaaron Swiftblade]

wait 'bout a week

[DrBoar]

The G5 have been benchmarked only by Apple and while they have a interest in making Intel look bad compared with the G5 they do not have the same interest to make the G4 look bad do they

The more the G4 get spanked the less appealing the Powerbooks and iMac and eMacs will look. Hmm, were did it put that thorny cane?

[osiris]

If the G4s were compared with the G5/P4, I imagine sales would come to a halt.

Barefeats did a few tests and the results are interesting considering unoptimized code and a 32 bit OS. For what it's worth:

Barefeats G4/G5 comparison

[bmmp]

The one thing these tests prove is that all Operating Systems and Programs only run as fast as they are designed to. Hardware isn't the only factor.

Since this is brand new architecture, it may be wiser to take advantange of cheaper G4 deals while developers adjust to the next step.

However, Adobe released a G5 update the very next day. If every one follows suit, who knows. Depending on your industry, you might not have to wait long.

I would really like to see real results with current programs. No one is going to go out and buy brand new programs along with their G5. It has to run all the programs that they currently own for Classic and Jaguar, while making it a worthwhile $2000+.

[Misanthrope]

It's worth noting that the current batch of G4s have 4 vector units and the G5s have 2...

[Apple Pro Underwear]

g5 is a new paradigm

wait a year for everything to catch up to it.



even now, the g4 has been optimized after the 3 years or so it has been in existence. the g5 is already better now and will probably age better than the g4.

[bmmp]

what are vector units used for?

[eggman]

Originally posted by bmmp:
what are vector units used for?

Concurrently performing a single operation on multiple pieces of data simultaneously.

This is typically useful for digital image processing (where the processor might perform a calculation on the red, green, blue and alpha component of a pixel in parallel rather than having to do them in sequence.... and there are also comparable operations in digital audio mixing and compositing video.

These are all applications where you have to crunch through large sets of homogenous data.

[Big Mac]

I'm not really a programmer, but here's my understanding of the Altivec issue. Yes, the G5 has a weaker Altivec/Velocity Engine unit than the modern G4. Scores on synthetic benchmarks will perform more poorly because of this as well as other issues. (I've heard, for example, that there's certain Altivec code in Xbench that really slows things down on the G5.) However, as I said before dedicated benchmarks are synthetic and not necessarily representative of real world application use. Real world applications have a lot of vector data to process, as opposed to the small, tight vector code in dedicated benchmark applications. The G4 may do well with those small chunks of vector code, but the G4 is constrained severely by its front-side bus. The idea here is that the G5s massive FSB bandwidth more than compensates for the comparative weakness of the G5 Velocity Engine itself. The tests conducted by the Nasa employee (and widely reported on the net) support that conclusion. He stated, in fact, "vector performance of the G5 remains excellent, and is inline with current G4 systems on a per clock cycle basis."

[blackwind]

About the number of vector units the G5 has versus the G4, I would like to correct Misanthrope that both the G5 and the PowerPC 744x/745x (latest G4 processors) have 4 vector units. They are: vector permute, vector simple integer, vector complex integer, and vector floating point.

You are probably mistaking the two-instructions dispatch to the G5's Altivec units for the number of Altivec units the G5 has.

To further clarify, both the PPC 744x/745x and the PPC 970 (the G5) have two instructions dispatched to their respective Altivec units.

The difference, however, is how the instructions get to the actual Altivec units.

In the PPC 744x/745x, the two instructions can be dispatched to any combination of vector units. In the G5, however, the two instructions are sent to "vector issue queues". One vector issue queue sends one instruction to the vector permute. The other vector issue queue sends the other instruction to one of either the vector simple integer, the vector complex integer, or the vector floating point.

As a result, if one of the two vector instructions dispatched to the computer is always a vector permute, then functionally there would be no difference between the G4 and the G5's Altivec behavior.

If the two instructions consist of vector simple integer, vector complex integer, or vector floating point only, the G5 has to send one instruction after the other rather than simultaneously as the G4 can.

As such, the G4 theoretically has a more versatile and robust Altivec implementation than the G5. The G5 has an advantage in high-bandwidth Altivec code, though. The G4's Altivec units have always been starved by the 100-MHz, 133-MHz or 167-MHz system buses that Apple used in their Power Macs and PowerBooks.

Those above two factors are why the G5 is beaten in Altivec benchmarks in so many synthetic benchmarks seen to date (Altivec Fractal Carbon, Xbench). The synthetic tests use very small data sets that do not require high bandwidth and do not involve much transfer of data between the CPU and memory. Add the fact that vec_dst is almost always used in G4 Altivec code but kills G5 performance (software prefetch seems to mess up the G5's hardware prefetch), and the G5 is wasted by a lower-clocked G4 in Altivec code.

Edit: Sorry about my long post. At the bottom, I basically just restated what Big Mac just said in his post. He is also correct about NASA's Jet3D performance, which is bandwidth-dependent. As such, the G5 actually had a better per-MHz Altivec performance than the G4's in the test.

[Eug Wanker]

Originally posted by Big Mac:
The idea here is that the G5s massive FSB bandwidth more than compensates for the comparative weakness of the G5 Velocity Engine itself. The tests conducted by the Nasa employee (and widely reported on the net) support that conclusion. He stated, in fact, "vector performance of the G5 remains excellent, and is inline with current G4 systems on a per clock cycle basis."

FYI, Dr. Hunter has been going over his Jet3D code, and predicts that a dual G5 might be over twice as fast as a dual 1.42 G4 after he optimizes his code for the G5.

Right now, with no G5 optmizations, it seems the dual 2.0 G5 is just under twice as fast as the dual 1.25. This means that, the G5 is slightly faster MHz/MHz than the G4 (around 7% faster per MHz), with unoptimized code. If after optimization, the G5 dual 2.0 were twice as fast as the G4 dual 1.42, then that would mean a G5 is about 1.4X the speed of a G4 on a per MHz basis. That's a whopping 1/3rd performance increase over the unoptimized code. Of course, this only applies to his code and we haven't seen the real numbers yet, but it does illustrate the potential speed of this chip. (One caveat to keep in mind though is his app doesn't have much integer code compared to many apps, and integer is where the G5 is generally considered weak.)

Unfortunately, he doesn't own his own G5, so I'm not sure if will see these numbers any time soon.

BTW, in case you have not seen them before, here are his numbers for the unoptimized code: