Apple's G5 Speeds Challenged

An anonymous reader was the first of a seemingly infinite stream of people to submit a URL to an argument that makes the case that the G5 isn't quite what Apple wants you to think of it. The evidence? Apple's own press material. Worth a read.

Comments

Standard Pratice

[ebuck]

I can vouch for those unfortunate enough to have worked in the grocery industry (and have an idea of what that kind of mechandising entail) but this is hardly insightful. It happens on nearly everything that you buy.

When asking the pricing managers (which work for the chain, not an individual store) they replied that there was a study once done, indicating that there is a psychological tendancy to shy away from certain "maker" numbers as being too big. For example, the masses statistically believed that twenty dollars was too much to pay for item x, but for some reason, nineteen ninety-nine was not too much to pay for the same item. Funny thing is that with the same item, eighteen dollars would again be too much, but seventeen ninety-five wouldn't.

Even if the study is flawed or bogus, it is still being taught in the "front-line" marketing schools, (ie. grocery, drug-store, clothing, etc.) , and so I expect we will see nineteen ninety-five for many many years to come.

Re:Benchmarking Across Platforms

[FrenZon]

Does anybody have any numbers for any other programs other than Photoshop? At least some fps in Quake 3?

You mean like the G5 Quake3 benchmarks on this page?

Re:Quite

[splanky]

32 bit memory addressing is 4GB not 2GB.

Re:Benchmarking Across Platforms

[babbage]

If Apple did indeed gain anything by mucking about with the configurations (and it sounds like they did), who's to say that they did anything more than offset similar mucking about on the other side of the fence?

There is no saying which is right, and I don't think this guy was really trying to. If you read his writeup, he says that Apple claims a certain Dell model benchmarks at value $X, while Dell claims that the same model can do $Y.

He doesn't actually say that one or the other is correct -- he says that the most charitable thing you can do is split the difference and go with the average -- and the kicker is that even that midway point is higher than what Apple claims for the G5.

You've got a good point, but I think this guy is aware of it as much as you are. He's not saying that each vendor's analysis is authoritative, but that the truth probably lies somewhere in the middle, and that middle ground might or might not look to be in Apple's favor (in fact, it doesn't seem to be in Apple's favor).

The benchmarks are fair!!

[EccentricAnomaly]

At work, we just bechmarked the Dell systems a month ago and got very similar results to Apple for the "base" rate. The article seems to be quoting the "peak" rate for the Dells. It's not valid to compare peak rates yet because gcc 3.3 and os 10.3 aren't really fully optimized yet.

The article also complains that using the NAGWare compilers is not a valid test since they're too slow. But I think the NAGWare compiler is a more vallid comparison than intel's compiler because most real-world computing is done with NAGWare because it fully implements the F95 spec and is more portable. In addition NAGWare is well tested for accuracy and it also very much cheaper.

The Dell benchmark numbers are pure fantasy. They never occur in real-world use.

Here's a more objective look at the benchmarks.

[merdark]

I just read the veritest document myself. This guy did not show the complete picture at all. First, in favour of Apple, these tests were run on Mac OS X 10.2.7. I don't think this is the 64-bit kernel that can really take advantage of the G5. I'm not a mac head, but I'm guessing this is Smeagol?

So right from the start the G5 is seriously crippled in these tests. Especially if they don't even take advantage of 64-bit as seems to be the case. Now, on the the other points that the spl dude makes.

Sure the special malloc library seems a bit unfair. But then again, do these tests really focus on memory allocation? I'd think they are limited by CPU power more than memory allocation. In any case, it'd be nice if we saw results without this library.

Now for the comfusing part. The 8300 only has a single cpu. For the base tests, they use hyperthreading and an SMP kernel. They do the exact same test for the 650's base test, hyperthreading with a single processor and an SMP kernel. The G5 system is run with a single processor as well.

So it seems this test is well balanced and fair. The confusing part is the rate tests.

For the 8300 they have no hyperthreading and a uniprocessor kernel. For the 650 they have no hyperthreading and an SMP kernel with two processors. The G5 system is run with two processors. It's unclear why they chose not to use hyperthreading on the rate test. It could be that hyperthreading actually reduced the scores of these tests. I'm no expert on the SPEC tests and hyperthreading, but what I do know is that hyperthreading is an intelligent technology. It can't always increase speed, it depends on what kind of code it's running. In the rate test it's possible that hyperthreading is unable to yeild any improvements, in which case the overhead of enabling hyperthreading may make the scores worse than without hyperthreading.

At anyrate, the tests were a LOT more fair than the dpl guy makes them out. And considering that the G5 could be seriously crippled by not running 64-bit and who knows what other optimisatoins, I'd say that the numbers are still impressive.