Re: [Fed-Talk] A suggestion for X-SERVEs
Re: [Fed-Talk] A suggestion for X-SERVEs
- Subject: Re: [Fed-Talk] A suggestion for X-SERVEs
- From: Michael Kluskens <email@hidden>
- Date: Thu, 17 Feb 2005 10:48:16 -0500
On Feb 17, 2005, at 10:04 AM, Michael Johnson wrote:
My first Xserve RAID and Xserve installations were in an SGI Origin
3400's rack.
Mine was into a Origin 2400 rack, I suspect the rails are spaced
differently, we had to use the Apple supplied rails in a nonstandard
configuration, basically folded back upon themselves, also I had only
1/2" clearance beyond that needed by the Xserve & RAID. The space with
our Origin 2400 is closed or I'd measure the spacing, as I remember the
short rail configuration for the Xserve when extended to the max was
just a bit too short and the long rail configuration couldn't be
shortened enough; however, if you took the long rails and bolted the
rail ends on in the reverse direction then you could adjust the length
to fit.
On Feb 17, 2005, at 9:39 AM, Michael Kluskens wrote:
Not the performance comparison you expected, that's because FDTD
moves massive amounts of data to and from the main memory
continually, ...
The tests we did used massive amounts of data.
Using massive amounts of data is a lot different from moving massive
amounts of data continually. For more than 90% of the CPU time used
FDTD codes takes seven floating point numbers from main memory, does 2
multiply operations and 4 additions, and places the answer back into
main memory. That totally flushes all the caches continually. The old
SGI Power Challenge was brought to it's knees by a FDTD code, it had
all the CPUs separated from the memory.
I'm sure a good computer architecture guy could figure out the memory
bandwidth required for a given CPU (based number of clock cycles per
addition and multiplication).
Altivec will help, although nothing we did in our code used those
optimizations.
I'm not surprised the G5s do great on FFTWs even without Altivec
optimizations, per memory load the number of operations required is
most certainly much higher than in FDTD codes. FDTD codes run a small
faction of normal speed if any swapping to disk is involved, most
certainly the ratio of memory access divided by disk access time.
Actually, AltiVec might help with FDTD codes because one of the
examples given either on Apple's site or another site is a speed up for
a CFD code which based on the description seems to do similar
operations, perhaps there are other differences I'm not aware of. Some
day I hope to find out one or another way. I'd like to test larger
problems on a G5 and compare against our existing Unix computers but
until I benchmark our most important codes (they are not all FDTD) on
all our best existing machines here I can't ask anyone to buy more
memory for the one dual 2 GHz G5 I have access to, nor can I justify
putting a lot of time into this project. Actually I have access to
three different FDTD codes, I hope to eventually test all three, so far
I only tested one.
Any advantage in testing codes on an OS X machine with the GUI or some
other default processes shutdown? When dealing with codes sensitive to
swapping I've found that even kernel processes using very little CPU
time can have an impact on the timing.
PS Are there any other Michaels on this list who have yet to respond
to this thread?
I noticed that.
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden