[MITgcm-support] new cluster advice
Blundell J.R.
jeff at noc.soton.ac.uk
Mon Feb 16 11:11:39 EST 2009
Just to echo Martin's comments: CFD codes all suffer from this problem. I suspect
MITgcm is one of the better ones, since it is really well structured, but the underlying
problem is intrinsically hard in that CPU, memory bandwidth (and network performance
if running in MPI parallel) ALL need to be good to do CFD well.
Regarding quad core:
(1) You may find quad core no more expensive than dual-core, so you may not lose
out with quad-core, and they might prove useful for other applications. Just don't
expect full 4x speedup.
(2) (My main point) quad-core systems do seem to be turning the corner regarding
memory bandwidth. In December (after earlier thread) I went to a talk on forthcoming
processors for scientific applications. AMD have a new quad-core processor codenamed
"Shanghai" coming out around now, which seemed to give a significant improvement
in memory bandwidth, which made them seem very appealing. However Intel also have
a new generation of quad-core codenamed "Nehalem" coming later this year. Results from
these were embargoed, but I got the impression that they might well outperform "Shanghai".
[No, I do not understand what these processor names are all about].
So the message is that quad-core seems to be turning the corner during 2009, and should
finally deliver its potential to our unusually demanding application area. So, don't rush to
buy, understand where what you are offered fits into the stupidly named processor roadmap,
and if at all possible benchmark MITgcm (or at least insist that vendors try to sell to you on
the basis of other CFD benchmarks, not stuff from other subject areas that isn't a good proxy).
Good luck with your procurement.
Jeff Blundell
======================================================================
| e-mail: jeff at noc.soton.ac.uk |
| Jeff Blundell, Room 256/09 | Ocean Modelling & Forecasting, |
| phone: +44 [0]23 8059 6201 | National Oceanography Centre, |
| fax : +44 [0]23 8059 6204 | Southampton, Empress Dock, |
| | SOUTHAMPTON SO14 3ZH, UK. |
| WWW: http://www.noc.soton.ac.uk/omf/ |
======================================================================
________________________________________
From: mitgcm-support-bounces at mitgcm.org [mitgcm-support-bounces at mitgcm.org] On Behalf Of Martin Losch [Martin.Losch at awi.de]
Sent: 16 February 2009 07:52
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] new cluster advice
Hi Mike,
did you get an answer to your question? I am no specialist, but I have
had very bad experience with quad-core proocessors, because of memory
access bandwidth (see a thread in October 2008). Apparently, the
MITgcm (as most other CFD/GFD codes) have a low "computational
efficiency" (FLOPS per memory access), so that the memory access of
the cores must be fast, and in quad cores the core appear to compete
for memory access causing a drastic performance drop. So my advice is
to advoid quad-cores (or at least not to expect 4times the performance
with quadcores).
Martin
On Feb 12, 2009, at 6:06 PM, Michael A. Spall wrote:
> Hi All,
>
> I am looking to purchase a new linux cluster and am wondering if
> anyone has advice. It needs to be pretty small initially, but
> expandable
> (I have something like 25-30k to start). Any advice on manufacturer,
> processor, buy now or wait for something in ~ 6 months?
>
> Thanks,
> Mike
>
> --
> ==================================================
>
> Michael A. Spall
> Department of Physical Oceanography
> W.H.O.I. MS #21
> 360 Woods Hole Road
> Woods Hole, MA 02543
>
> mspall at whoi.edu
> (508) 289-3342 (office)
> (508) 457-2181 (fax)
>
> =================================================
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org
http://mitgcm.org/mailman/listinfo/mitgcm-support
More information about the MITgcm-support
mailing list