Slashdot Mirror
NASA Benchmarks the New G5 Powermac
sockit2me9000 writes "Well NASA's Langley Research Center recently benchmarked the new G5 dual 2ghz Powermac against a dual 1ghz Xserve, a dual 1.25 ghz Powermac, a Pentium4 2 ghz, and a Pentium4 2.66 ghz. To make things fair, the second processor in the G5 was switched off, as well as the other dual sysytems. Then, they all ran Jet3d. Even with un-optimized code and one processor, the G5 performance is impressive."
Because I have a strong feeling this is going to be asked:
;)
For those of you who were wondering, you too can switch off one of your Mac's dual CPU's with the Apple CHUD Tools. Look near the bottom of the page. It'll make you appreciate your second processor
Personally though, I want to see how well it runs Seti@Home.
Vonal Declosion
It is interesting to note that they used the Portland group compiler instead of the intel compiler. For the CFD code that I work on (which is mostly Fortran), the Intel compiler produces much faster code than the Portland group compiler (as much as 50%).
Translation: Slower than the P4 for anyone who didn't look at the grid.
Real Translation: 0.4% slower, at 75% of the clock speed.
$2999 for the mac 2x2ghz
creation science book
I hope they didn't use gcc (the yet-another free and hopeless compiler).
It should be noted that Apple uses gcc to compile Mac OS X and most of their applications, so it would be appropriate to use gcc on the G5. Intel's compiler might be a more appropriate choice for the Xeon.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
If there budget is such that dualie 2Ghz G5's are a possibility...
Budget had nothing to do with it; the PowerMac G5 isn't shipping yet. NASA had to have obtained theirs through a special arrangement with Apple.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
If one thing is 80 dB and one is 90 dB, the second object is twice as "loud." Each 10 dB jump either doubles of halves "loudness." ie: If you're at 1000 dB vs 1010 dB, the 2nd object is twice as loud.
So, based on what was said at the keynote (and my interpretation), the G5s are 10dB quieter. Twice as quiet sounds more impressive. Note that saying "half as loud" still implies "loud" so psychologically it's not as impressive.
If I'm wrong, I'm sure someone will jump on me soon enough. I'm holding on tight.
I think it's pretty obvious why they tested the G5: their Altivec program is 13X faster than their scalar program. They don't mention the SSE2 so I assume they have an investment in Altivec programs. Therefore they would naturally be interested in comparing the G5 versus the XServe and G4. Until Intel releases the 34.5GHz P4 (13X 2.66GHz), there doesn't seem to be any reason to run out and buy a latest P4 just for this comparison.
And surely the version of RH Linux hardly matters. Maybe they benchmarked using this OS because (shock, horror) it is what they use daily.
Hyperthreading isn't a magic double-the-speed-of-your-processor feature. In fact, ti can slow a computer down. What it is nice for is for running multiple threads or programs more efficiently.
Found this from last Jan:
Date: Mon, 13 Jan 2003 23:29:38 -0500
From: Craig Hunter
Subject: G4 vs. P4 performance
I have been following the discussion of Rob Galbraith's benchmarks with much interest, as I have spent a good deal of time testing, optimizing, and benchmarking software for the G4 (OS X) and P4 (Linux).
The first thing to realize is that there are numerous benchmarks that show the P4 is faster, and there are numerous benchmarks that show the G4 is faster. What matters? Well, probably the benchmarks that apply to the kind of work you do. For people doing photo processing with the software Rob tested, his results are extremely relevant. But, someone working with a program optimized for AltiVec and dual processors might have a completely opposite experience.
Just to give an example of a benchmark that goes the other way, see this chart.
(You're welcome to mirror this benchmark image, since my web site may not handle a lot of traffic). These real-world results come from the Jet3D computational fluid dynamics noise prediction software, which I developed for my doctoral thesis and currently use in my work at NASA. Jet3D is written in a combination of FORTRAN 77, FORTRAN 90, and C, and is optimized for AltiVec and dual processors on G4 hardware. When compiled on Linux using Intel's ifc compiler tools, Jet3D also becomes optimized for the P4 (using the various SIMD extensions available on the P4).
As you can see, the G4 does quite well here. A dual processor 1.25GHz G4 system is more than 3.5X faster than a single processor 2GHz P4 system. Though it's not shown on the chart, a single 1.25GHz G4 processor benchmarks at about 1589 MFLOPS, 1.9X faster than the P4. If you look at MFLOPS per MHz for a single processor, the G4 comes in at 1.27 MFLOPS/MHz, while the P4 comes in at 0.42 MFLOPS/MHz. If you want a good example of the MHz myth, look at the Cray, which comes in at 1.78 MFLOPS/MHz with only a 500MHz processor, beating both the G4 and P4.
Without AltiVec, the Jet3D benchmark would be about 794 MFLOPS on the dual-1.25GHz G4, which erases the performance lead over the P4. And then, using only a single processor, the 1.25GHz G4 benchmarks at about 418 MFLOPS, which is about half as fast as the P4. And all of a sudden, the G4 doesn't look very compelling. For the Jet3D benchmark, AltiVec and dual processors are key (AltiVec more so than dual procs). This is true for most benchmarks I have looked at; thus numerically intensive applications that can't use AltiVec and/or dual processors are likely to suffer on the G4.
In the case of Jet3D, it was easy to optimize for AltiVec. I was able to hand-vectorize about 10 lines of code within the guts of the FORTRAN algorithm and convert the computations to C for easy access to AltiVec hardware instructions. It had a huge effect for not a lot of work. For other more complicated cases, it may be possible to use the VAST compiler tools to automatically vectorize and tie in with AltiVec (VAST has parallel tools also). But in some cases, vectorization is not possible or feasible. In those instances, you're stuck with the processor's scalar performance, and the P4 generally has better scalar performance than the G4 in my experience. One final note: these are my personal views, and do not represent the views of NASA Langley Research Center, NASA, or the United States Government, nor do they constitute an endorsement by NASA Langley Research Center, NASA, or the United States Government
More relevant, perhaps, are the figures in the raw MFLOPS graph:
Alas, difficulties in cross-platform benchmarking rear their ugly head:Scalar Code:
G4 using Absoft F90 v8: f90 -s -O -lU77 -N11
P4 using Portland Group F90 v4.0-3: pgf90 -byteswapio -tp p7 -O1
The author did apparently make an effort to use the compiler and flags best suited for each architecture if I read this correctly....
I don't know how much I trust NASA tho. Afterall, they only do RealMedia and WindowsMedia streaming media. Perhaps there's some bias there in favor of Windows (yes, I realize that the testbed P4 system ran Red Hat. Lighten up)
Apple claims 15.7 for the Dual 2GHz G5, and the 3GHz P4 getting an 8.07. NASA gives the Dual 2GHz G5 498MFLOPS and the 2.66GHz P4 255MFLOPS.
If you use your math skills: 15.7 / 8.07 about equals 498 / 255. So therefore we can draw the conclusion that they have similar results.
Now, NASA only used a 2.66MHz P4 while Apple used a 3GHz P4. Although remember NASA's figure that the P4 had 0.096 MFLOPS/MHz? Give the P4 333 more MHz, and you find it has about 286.968 MFLOPS. NASA also suggests a 20% performance increase can be expected with compilers that take advantage of the G5.
Although, even without this increase Apple's benchmark and NASA's benchmarks are very close. Which would lead one to draw the conclusion that Apple's benchmarks were in fact valid.
I should also note that a P4 would not perform as well in a dual system as the G5 does. So your 500 MFLOPS number is a little rediculous. The G5 which is an amazing dual proc chip saw it's 254 MFLOPS for a single processor (508 when doubled) drop to 498 MFLOPS in a dual system. And the P4 isn't designed for a dual system, doesn't support HyperTransport, etc.
Dak
I'm only running 10.2.6, and Software Update says nothing new is available.
MacOS X 10.2.7 - codename Smeagol - is a stop-gap solution to provide JUST ANY working OS to the G5's until Panther is ready for prime time. Your Sofware Update is right not to install it on your machine, as most probably it is not a G5, sir.
How about a more fair comparison? Namely, between similarly configured high-end single-processor systems:
Apple PowerMac G5:
1.8GHz PowerPC G5
250GB Serial ATA - 7200rpm
SuperDrive (DVD-R/CD-RW)
512MB DDR400 SDRAM (PC3200)
Mac OS X
AppleWorks
ATI Radeon 9800 Pro
56k V.92 internal modem
No Monitor
$2874
Dell Dimension XPS:
3.2GHz Pentium 4
200GB Ultra ATA - 7200rpm
DVD+RW/DVD+R/CD-RW
512MB DDR400 SDRAM
Microsoft® Windows® XP Professional w/ Microsoft® Plus!
Microsoft® Works Suite 2003
ATI Radeon 9800 pro
No Monitor
$3062
And if you are to believe the benchmarks, it seems that Apple is selling the faster system for a lesser price than a similarly configured Dell.
Apple has never competed at the low end. It is not starting now.
-Mike
Schrödinger's cat is not amused—maybe.
I recently got the chance to do a testrun, doing some airflow simulation on a G5 1.8GHz demo machine, and with altivec optimizations it clocked in at roughly 2100MFLOPS average for 5 runs(I could probably get better results with a better compiler though), while the dual Opteron 1.8(which the place where I did the testrun has bought 10 boxes of for their renderfarm), running Suse Linux, and my program re-compiled for x86-64 and SSE2 performed at about 2960MFLOPS average, but that could probably be improved with a better compiler too, but I had to use GCC at this time. Both machines had 4GB RAM btw.
Go back and read the article. You have no idea what you are saying.
1) One of the Mac's processors was disabled
2) 195.3% advantage was on an MFLOP/MHz basis
That is how they are comparing the architechture of the chip and it's performance outside of a MHz pissing race. They are in the same ballpark now MHz wise so why shouldn't they take a look at how the actual chip performs. Not to mention how much more will likely come out of the chip with maturing compilers to take advantage of the arch.
Bah!
Actually, you're both correct, and you're both missing something.
.18u, .15u, .13u, etc) means there's less time necessary to charge the capacitors, and thus speeds are increased. (This is only one aspect, and I'm no expert here).
Originally, the pipelining was segmented based on the I-Fetch, D-Fetch (register/etc), Exec, Reg-Write-Back, with expensive floating point doing with different timing considerations (externalized or delay-locking multi-stage execution). Then they started sub-dividing each of those stages (especially in CISC archetectures). Now its common to see 15 integer execution pipeline stages - either with shared resources, such that you can only have one divide occuring at any given time (early P-I, P-II, P-III), or with fully independent/concurrent resources (AMD's Athlon).
The addition of the pipelinable-stages between I-Fetch, D-Fetch, exec, and WB was somewhat trivial, because prior to pipelining, there were still seperate events on seperate clock-ticks with inter-stage latching. However, in CPU's with exec-stages that are pipelined, you are introducing additional latches that cause additional undesirable propagation delays.
So a 15 stage integer multiply unit (excluding fetch/WB) has 15 x [guestimating] 4 propagations of additional latency over a single-stage I-unit. If there are resource-based stage-interlocks, or worse data-dependencies, then the pipelining is useless and you're totally hit by the excess propagation delays.
Still, marketing being what it is these days, adding more stages means less propagations per stage, thus less worst-case propagation time, and thus higher clockability (all else being equal; temperature, etc).
The P4, however, compensated by double-clocking the core integer stages, so the number of advertised stages is somewhat misleading.
On a side note, due to the latching in pipelining, you're definately doing more total work for a given instruction. And more importantly, the designers have to think of totally different logic-algorithms to efficiently pipeline than to single-stage. My guess is that the pipelined versions will always be less efficient (especially considering that not all stages will fully utilize their allotted clock-time), and thus there's an additional loss.
Ok, so this supports your post, but here's the part about power/heat.
There are two types of transistors used in modern CPUs (everything past the Pentium). BiPolar and Field-Effect. The CMOS-FET refers to Complementary Metal-Oxide-Semiconductor Field-Effect-Transistor. This acts similarly to a capacitor in that there is a charge and discharge time with little waste current, and power dessipation is typical V=IR, Pwr = I^2 * R. The gate capacitor charge-time is the killer, and what limits switching speed (and thereby clock-speed). Shrinking the area of the capacitor (related to the micron-size stated,
There's another way of reducing switching speed.. Increasing the amount of current running through the wires that ultimately charge/discharge the gate-capacitors. FETs are poor amplifiers, but BiPolar (while more complex and harder to make small) are phenominal. In addition to their complexity, Bipolar also are power hogs. While a FET only consumes power while turning on or off, BiPolars are always on, consuming power (there is current bleeding from the switch). So what often happens is that designers sprinkle BJT's here and there to amplify the current (at the expense of cost/complexity and power-dessipation), and continue using FETs everywhere else.
The bigger and greater number of BJTs that are used, the faster some heavily loaded FET gates will charge and the quicker their switching time will be.
If you up the voltage on a CPU, you're enhancing the amplifier's ability to charge the capacitors and thus gives you more safety-room to up the external clock-speed.
Again, this deviates somewhat from my knowledge domain, but you can often merely co
-Michael
Plus or minus 3dB represents a doubling or halving of the power, respectively. However, quietness or loudness is a subjective quality. Most statistically normal humans seem to agree that plus or minus 10dB doubles or halves the apparrent loudness. Psychoaccoustics bears no relation to math or physics.
Wrong Conclusion!
According to this pdf (page 13) G5 @ 1.8GHz has 1051 SpecFP.
At the same time Power4 @ 1.7GHz has 1598 SpecFP !!!
It is very clear that Power 970 (G5) is much-much slower in floating point than it's Power4.
Well, first of all, I work at NASA as a researcher, doing numerical work (although I'm not a civil servant, and don't speak for them).
:)
I agree that AltiVec is superior to SSE (ie. single precision), but you compared it to to SSE2, which is a bit apple-to-oranges (no pun intended, btw). If the G5 FPU is faster than current SSE2 at double precision, it just proves the well thought out design of the PowerPC architecture (and the unfortunate legacy of Intel's FPU instruction set, which is still a handicap even with SSE/SSE2, due to the need to mode switch).
But SSE2 is still immature, and I expect compilers to improve, as well as chip implementations. Once they do, a more meaningful comparision can be made.
The Intel chips NEED stuff like SSE/SSE2 to achieve faster floating point speeds, whereas the PowerPC can get by without it, thanks to a much better FPU design, and thus, PowerPC makers will probably not spend the silicon to make a double precision SIMD instruction set anytime soon.
I stand by my claim that while most consumer and media software can get by with single precision, scientific computing (ie. large matrix calculations, to be blunt) quite often needs double precision (hell, you can get libraries that use 128 bit long doubles, these days), and will ultimately prefer SSE2. Scientists fuss with single precision SIMD simply because many of their applications can benefit so much from SIMD that it is worth the pain to use single precision (with proper conditioning and verification, etc.) Now that double precision SIMD is available, I can only predict they will want to jump to it, once tools for using it are there.
Granted, if Intel can't make a double precision SIMD unit that outperforms a double precision general FPU like the G5's, for matrix problems, then they don't deserve to design chips for scientific computing.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward