But its also true, assuming Sean's single processor performance is optimal
or close to it, he would not see much scaling anyway, given that the G5 2p
system does not scale well, as a single memory controller is shared between
the two DIMMs? At least when I did the STREAM benchmark's that was clearly
the case. If his code is optimal he should see good b/w for a single proc
(3-4 GB/s range) and in the same nbhd for the 2p case.
The important question is, has the design been tweaked for improved scaling
in a dual Xserve node.
-- Avi
On 1/22/04 7:19 PM, "Yusuf Abdulghani" <email@hidden> wrote:
> Sean,
>
> Did you profile your code and see where are you spending your time in
> the code? What is your memory access pattern? What compiler/compiler
> options are you using to compile your code?
>
> Profile using Shark (profiling tool that comes with CHUD performance
> tools) and see if you can determine why you are not seeing as much
> scaling as you were expecting to see on the dual G5 system.
>
> Yusuf
>
> On Jan 22, 2004, at 3:45 PM, Sean C. Garrick wrote:
>
>> I've been doing some more benchmarking using two homegrown CFD codes,
>> this time with Opterons and PPC-970s (G5).
>>
>> Here is a typical single processor result :
>>
>> Small memory code (110 MB): Time Opteron / Time G5 = 2.3
>> Opteron: 85 seconds
>> G5: 36 seconds
>>
>> Large memory code (450MB) Time Opteron / Time G5 = 1.9
>> Opteron: 454 seconds
>> G5: 237 seconds
>>
>> While the G5 is faster, the Opteron seems to have a better memory
>> access/bandwidth.
>>
>> Also, I ran a job one job on the G5 using 1 processor and another
>> using 2 processors. The speed-up was only 50%. I did the same thing on
>> the Opteron and the speed-up was 83%!!!
>>
>> I'm not sure what type of board the Opteron was built on but this is
>> very surprising as Apple was touting its motherboard as having the
>> most bandwidth. I think the performance is quite poor and I'm
>> wondering its worth getting 2 CPUs per board or just go with one?
>>
>> Any ideas?
>>
>> Thanks,
>> Sean
>> _______________________________________________
>> scitech mailing list | email@hidden
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/scitech
>> Do not post admin requests to the list. They will be ignored.
> _______________________________________________
> scitech mailing list | email@hidden
> Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/scitech
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
scitech mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/scitech
Do not post admin requests to the list. They will be ignored.
