<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Ed,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I'm just doing the same exercise on the same machine for the same bid. My configuration has 42x504x3640 points and another one 150x504x3640. I get a super linear speedup up to 630 cores and then it drops off rapidly (for both configurations, but more so for
the 42 vertical layers). So this must have something to do with that particular machine but no idea what. I'm also surprised that the perfect tile size is ~50x50 and not smaller, but this seems to be similar for you.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Andreas</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> MITgcm-support <mitgcm-support-bounces@mitgcm.org> on behalf of Martin Losch <Martin.Losch@awi.de><br>
<b>Sent:</b> Monday, 19 October 2020 7:02 PM<br>
<b>To:</b> MITgcm Support <mitgcm-support@mitgcm.org><br>
<b>Subject:</b> Re: [MITgcm-support] Better than expected HPC Scaling</font>
<div> </div>
</div>
<div>Hi Ed,<br>
<br>
certainly not my field of expertise, but could you use the profiing information at the end of STDOUT to figure out which parts of the code are scaling superlinearily? E.g, it is dyanmics (solve_for_pressure, probably not) or thermodynamics, maybe that can give
you a clue.<br>
<br>
Did you check out<br>
<a href="https://en.wikipedia.org/wiki/Speedup#Super-linear_speedup">https://en.wikipedia.org/wiki/Speedup#Super-linear_speedup</a><br>
for more possible reasons?<br>
<br>
Martin<br>
<br>
> On 15. Oct 2020, at 00:07, Edward Doddridge <edward.doddridge@utas.edu.au> wrote:<br>
> <br>
> Thanks Matt and Dimitris.<br>
> <br>
> 48 cores is definitely a small number for a job like this, but I wasn’t pushing the memory limits – these cores all have plenty of memory (4GB per core). As for sharing the node, it’s a good thought, but each node has 48 cores (which is why I went in multiples
of 48). I also tried to keep the tiles as square as possible. They weren’t always perfect, but the 480 core run actually had slightly squarer tiles than the 384 core run and the 768 core run had perfectly square tiles.<br>
> <br>
> “Another possibility is that this is within the machine noise”<br>
> That’s certainly a possibility. I haven’t rerun all of the tests, but I reran a couple and the timings were very similar. The variation wasn’t enough to pull the curve below the ideal scaling curve. I don’t think this is noise. It seemsto me that there is
structure in the signal.<br>
> <br>
> Are you doing any I/O?<br>
> I’m not doing much I/O. I set it to output a few monthly mean fields, but that was all. Using the timing breakdown in STDOUT, the time spent in “DO_THE_MODEL_IO” scales pretty well with the core count (see attached).<br>
> <br>
> Cheers,<br>
> Ed<br>
> <br>
> <br>
> Dimitris Menemenlis menemenlis at <a href="http://jpl.nasa.gov">
jpl.nasa.gov</a> <br>
> Tue Oct 13 00:38:33 EDT 2020<br>
> <br>
> I like the theory of better cache utilization initially, from 48 to ~250 processors, then degrading @ higher processor count because of communications (and to a lesser extent more grid cells and hence more computations in the overlap regions).<br>
> <br>
> Are you doing any I/O?<br>
> <br>
> > On Oct 12, 2020, at 9:24 PM, Matthew Mazloff <mmazloff at <a href="http://ucsd.edu">
ucsd.edu</a>> wrote:<br>
> ><br>
> > Hi Ed<br>
> ><br>
> > It depends on the machine you are running on. But its only slightly better at 250 than 48, and 48 does seem a bit low for a job of that size. Maybe you were pushing max memory? It is odd, but I suspect you are on a machine that has very fast interconnects
and I/O and 250 is just more efficient.<br>
> ><br>
> > Another possibility is that this is within the machine noise. Or that you were sharing a node when you ran the 48 and 96 job. Or that your tiles were very rectangular for the 48 and 96 core jobs so you had more overlap.<br>
> ><br>
> > Matt<br>
> ><br>
> ><br>
> <br>
> <br>
> From: Edward Doddridge <edward.doddridge@utas.edu.au><br>
> Date: Tuesday, 13 October 2020 at 15:00<br>
> To: "mitgcm-support@mitgcm.org" <mitgcm-support@mitgcm.org><br>
> Subject: Better than expected HPC Scaling<br>
> <br>
> Hi MITgcmers,<br>
> <br>
> As part of an HPC bid I need to provide some scaling information for MITgcm on their cluster. The test configuration is a reentrant channel 600x800x50 grid points, using just the ocean component and some idealised forcing fields. As I increased the core count
between 48 and 384 the model scaled better than the theoretical scaling (see attached figure). I’m not complaining that it ran faster, but I was surprised. Any thoughts about what would cause this sort of behaviour? I wondered if it might be something to do
with the tiles not fitting in the cache for the low core count simulations. The bid might be more convincing if I can give a plausible explanation for why the model scales better than ideal.<br>
> <br>
> Cheers,<br>
> Ed<br>
> <br>
> <br>
> <image001.png><br>
> Edward Doddridge<br>
> Research Associate and Theme Leader<br>
> Australian Antarctic Program Partnership (AAPP)<br>
> Institute for Marine and Antarctic Studies (IMAS)<br>
> University of Tasmania (UTAS)<br>
> <br>
> <a href="http://doddridge.me">
doddridge.me</a><br>
> <br>
> <br>
> University of Tasmania Electronic Communications Policy (December, 2014). <br>
> This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained
in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.<br>
> <br>
> <Screen Shot 2020-10-15 at 09.02.33.png>_______________________________________________<br>
> MITgcm-support mailing list<br>
> MITgcm-support@mitgcm.org<br>
> <a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support">
http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
<br>
_______________________________________________<br>
MITgcm-support mailing list<br>
MITgcm-support@mitgcm.org<br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
</div>
</div>
</body>
</html>