<div dir="ltr">If it is memory bandwidth limited, you may want to consider AMD's EPYC which has 33% more bandwidth.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 16, 2018 at 3:41 AM, John Hearns via Beowulf <span dir="ltr"><<a href="mailto:beowulf@beowulf.org" target="_blank">beowulf@beowulf.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Oh, and while you are at it.</div><div>DO a bit of investigation on how the FVCOM model is optimised for use with AVX vectorisation.</div><div>Hardware and clock speeds alone don't cut it.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 16 February 2018 at 09:39, John Hearns <span dir="ltr"><<a href="mailto:hearnsj@googlemail.com" target="_blank">hearnsj@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ted,</div><div>I would go for the more modern system. you say yourself the first system is two years old. In one or two years it will be out of warranty, and if a component breaks you will have to decide to buy that component or just junk they system.</div><div><br></div><div><br></div><div>Actually, having said that you should look at the FVCOM model and see how well it scales on a multi-core system.</div><div>Intel are increasign core counts, but not clock speeds. PAradoxically in the past you used to be able to get dual-core parts at over 3Ghz, which don;t have many cores competing for bandwith to RAM.</div><div>The counter example to this is Skylake which has more channels to RAM, makign for a more balannced system.</div><div><br></div><div>I would go for a Skylake system, populate all the DIMM channels, and quite honestly forget about runnign between two systems unless the size of your models needs this.</div><div>Our latest Skylakes have 192Gbuytes of RAM for that reason. Int he last generation this would sound like an unusual amount of RAM, but it makes sense in the Skylake generation.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="m_-6925356268042943067HOEnZb"><div class="m_-6925356268042943067h5"><div class="gmail_extra"><br><div class="gmail_quote">On 15 February 2018 at 14:20, Tad Slawecki <span dir="ltr"><<a href="mailto:tslawecki@limno.com" target="_blank">tslawecki@limno.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><br>
Hello, list -<br>
<br>
We are at a point where we'd like to explore a tiny cluster of two systems to speed up execution of the FVCOM circulation model. We already have a two-year-old  system with two 14-core CPUs (Xeon E-2680), and I have budget to purchase another system at this point, which we plan to directly connect via Infiniband. Should I buy an exact match, or go with the most my budget can handle (for example 2xXeon Gold 1630, 16-cores) under the assumption that the two-system cluster will operate at about the same speed *and* I can reap the benefits of the added performance when running smaller simulations independently?<br>
<br>
Our list owner already provided some thoughts:<br>
<br>
> I've always preferred homgenous clusters, but what you say is,<br>
> I think, quite plausible.  The issue you will have though is<br>
> ensuring that the application is built for the earliest of the<br>
> architectures so you don't end up using instructions for a newer<br>
> CPU on the older one (which would result in illegal instruction<br>
> crashes).<br>
><br>
> But there may be other gotchas that others think of!<br>
<br>
Thank you ...<br>
<br>
Tad<br>
______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman<wbr>/listinfo/beowulf</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br>
<br></blockquote></div><br></div>