PowerMac G5 performance
24 Feb 2005 20:10:15 UTC
Topic 187961
(moderation:
I have a dual 2GHz PowerMac G5 with 2Gb of RAM, and the calculated CPU performance seems low to me. Looking at other systems that are Mac's, it seems my Floating point should be in the 2000's and my Integer in the 5000's, yet this is what it shows:
Measured floating point speed 1110.07 million ops/sec
Measured integer speed 3692.73 million ops/sec
Any suggestions?
PowerMac G5 performance
)
> I have a dual 2GHz PowerMac G5 with 2Gb of RAM, and the calculated CPU
> performance seems low to me. Looking at other systems that are Mac's, it
> seems my Floating point should be in the 2000's and my Integer in the 5000's,
> yet this is what it shows:
>
> Measured floating point speed 1110.07 million ops/sec
> Measured integer speed 3692.73 million ops/sec
>
> Any suggestions?
>
>
When you're running dual cpus, it divides the benchmark result in half (for each cpu or HT thread).
HTH
Seti Classic Final Total: 11446 WU.
> Any suggestions? > do
)
> Any suggestions?
>
do you have the optimized client? that will improve benchmarks with ease:
http://members.dslextreme.com/~readerforum/forum_team/boinc.html
> > I have a dual 2GHz
)
> > I have a dual 2GHz PowerMac G5 with 2Gb of RAM, and the calculated CPU
> > performance seems low to me. Looking at other systems that are Mac's,
> it
> > seems my Floating point should be in the 2000's and my Integer in the
> 5000's,
> > yet this is what it shows:
> >
> > Measured floating point speed 1110.07 million ops/sec
> > Measured integer speed 3692.73 million ops/sec
> >
> > Any suggestions?
> >
> >
> When you're running dual cpus, it divides the benchmark result in half (for
> each cpu or HT thread).
>
> HTH
>
I am aware of that. I run 2 units at the same time (one per processor). What bugs me is that my Athlon 3000+ 32-bit processor has better tested spec's than my 2GHz 64-bit processor on my G5. I have looked at some other people's G5's, and their performance was a lot higher. I know my Mac smokes my PC in SETI@Home classic. I also noticed top machines are Mac's...
Not aware of optimized client. Have to try to find it I suppose.
> > Any suggestions? > > >
)
> > Any suggestions?
> >
>
> do you have the optimized client? that will improve benchmarks with ease:
>
> http://members.dslextreme.com/~readerforum/forum_team/boinc.html
>
OK. Just downloaded the 4.19 optimized client for the G5. My Athlon still running faster. Only advantage the Mac has is it can do a WU per CPU. Speed per CPU lower than speed on a single CPU PC. I am watching graphics on the G5 that shows percent done along with search info for both processors, while watching graphics on the PC next to it, and the PC chugging past it. Oh well...
> OK. Just downloaded the
)
> OK. Just downloaded the 4.19 optimized client for the G5. My Athlon still
> running faster. Only advantage the Mac has is it can do a WU per CPU. Speed
> per CPU lower than speed on a single CPU PC. I am watching graphics on the G5
> that shows percent done along with search info for both processors, while
> watching graphics on the PC next to it, and the PC chugging past it. Oh
> well...
I have a similar G5 ... Dual 2.0 GHz
Measured floating point speed 1074.44 million ops/sec
Measured integer speed 3579.92 million ops/sec
So, it is not just you. Note, changing the Software to an "optimized" version only means that the benchmark goes up ... which raises the claimed credit. Unless it is an optimized science application, of which there is only the SETI@Home version as it is the only Project with open souce for the Science Application ...
My experience with the optimized versions is that they are not enough faster to make them worth while ... Note, there is work underway to refine and make better versions using the full capabilities of the processors.
My suspicion is that the G5 is indeed a better processor. But, if the compiler options and the code are not amenable to the specific CPU, well, a Cray would stink as a word processor...
I have a dual 2ghz and a dual
)
I have a dual 2ghz and a dual 2.5 and they are both running reasonably fast but not as fast as some of my x86 machines. However, as others have said before me I suspect the OS X binary is simply not well-optimized for our platform. Perhaps in the future they will have time to tune it better (or perhaps this project simply does not play well to the strengths of the G5, although since it's largely doing FFTs it should be able to take advantage of altivec). If they don't have the time to write SIMD code for a platform with just a few percent of the market, autovectorization support is coming in gcc 4.0 as well. :)
> I have a dual 2ghz and a
)
> I have a dual 2ghz and a dual 2.5 and they are both running reasonably fast
> but not as fast as some of my x86 machines. However, as others have said
> before me I suspect the OS X binary is simply not well-optimized for our
> platform. Perhaps in the future they will have time to tune it better (or
> perhaps this project simply does not play well to the strengths of the G5,
> although since it's largely doing FFTs it should be able to take advantage of
> altivec). If they don't have the time to write SIMD code for a platform with
> just a few percent of the market, autovectorization support is coming in gcc
> 4.0 as well. :)
Well, we cannot do the work on our own as the source is not available. Worse, they may not be using the Apple compiler. We may get lucky and Bruce will tell us which compiler they are using ...
> > I have a dual 2ghz and a
)
> > I have a dual 2ghz and a dual 2.5 and they are both running reasonably
> fast
> > but not as fast as some of my x86 machines. However, as others have
> said
> > before me I suspect the OS X binary is simply not well-optimized for our
> > platform. Perhaps in the future they will have time to tune it better
> (or
> > perhaps this project simply does not play well to the strengths of the
> G5,
> > although since it's largely doing FFTs it should be able to take
> advantage of
> > altivec). If they don't have the time to write SIMD code for a platform
> with
> > just a few percent of the market, autovectorization support is coming in
> gcc
> > 4.0 as well. :)
>
> Well, we cannot do the work on our own as the source is not available. Worse,
> they may not be using the Apple compiler. We may get lucky and Bruce will
> tell us which compiler they are using ...
We're using the Apple XCode tools (gcc 3.6). Recently one of our members has gotten altivec code running between 2 and 4 times faster under G5, partly by changing a number of internal double quantities to floats. Next week I'll do some testing to see if this new code is sufficiently accurate to use.
Bruce
Director, Einstein@Home
> We're using the Apple XCode
)
> We're using the Apple XCode tools (gcc 3.6). Recently one of our members has
> gotten altivec code running between 2 and 4 times faster under G5, partly by
> changing a number of internal double quantities to floats. Next week I'll do
> some testing to see if this new code is sufficiently accurate to use.
Bruce
Way cool!
Based on the number posted in another thread it shows that the G5 I have is doing an Einstein@Home WU in 8 hours compared to 8.5 or more else where ...
> > > I have a dual 2ghz and
)
> > > I have a dual 2ghz and a dual 2.5 and they are both running
> reasonably
> > fast
> > > but not as fast as some of my x86 machines. However, as others
> have
> > said
> > > before me I suspect the OS X binary is simply not well-optimized for
> our
> > > platform. Perhaps in the future they will have time to tune it
> better
> > (or
> > > perhaps this project simply does not play well to the strengths of
> the
> > G5,
> > > although since it's largely doing FFTs it should be able to take
> > advantage of
> > > altivec). If they don't have the time to write SIMD code for a
> platform
> > with
> > > just a few percent of the market, autovectorization support is
> coming in
> > gcc
> > > 4.0 as well. :)
> >
> > Well, we cannot do the work on our own as the source is not available.
> Worse,
> > they may not be using the Apple compiler. We may get lucky and Bruce
> will
> > tell us which compiler they are using ...
>
> We're using the Apple XCode tools (gcc 3.6). Recently one of our members has
> gotten altivec code running between 2 and 4 times faster under G5, partly by
> changing a number of internal double quantities to floats. Next week I'll do
> some testing to see if this new code is sufficiently accurate to use.
>
> Bruce
>
>
That will be awesome! Currently my Athlon 3000+ is outperforming my Mac on a per-processor basis (however the Mac does 2 work units at once). Would love to get its true power out...