<div dir="ltr">MArk, again I do not have time to give your answer justice today.<div>However, as you are in NL, can you send me some olliebollen please? I am a terrible addict.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 28 Nov 2018 at 13:52, mark somers <<a href="mailto:m.somers@chem.leidenuniv.nl">m.somers@chem.leidenuniv.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, please be careful in naming things:<br>
<br>
<a href="http://cloudscaling.com/blog/cloud-computing/grid-cloud-hpc-whats-the-diff/" rel="noreferrer" target="_blank">http://cloudscaling.com/blog/cloud-computing/grid-cloud-hpc-whats-the-diff/</a><br>
<br>
(note; The guy only heard about MPI and does not consider SMP based codes using i.e. OpenMP, but he did understand there are<br>
different things being talked about).<br>
<br>
Now I am all for connecting divers and flexible workflows to true HPC systems and grids that feel different if not experienced<br>
with (otherwise what is the use of a computer if there are no users making use of it?), but do not make the mistake of thinking<br>
everything is cloud or will be cloud soon that fast. <br>
<br>
Bare with me for a second:<br>
<br>
There are some very fundamental problems when dealing with large scale parallel programs (OpenMP) on virtual machines (most of<br>
the cloud). Google for papers talking about co-scheduling. All VM specialists I know and talked with, state generally that using<br>
more than 4 cores in a VM is not smart and one should switch to bare metal then. Don't believe it? Google for it or just try it<br>
yourself by doing a parallel scaling experiment and fitting Amdahls law through your measurements.<br>
<br>
So, one could say bare metal cloud have arisen mostly because of this but they also do come with expenses. Somehow I find that a<br>
simple rule always seems to apply; if more people in a scheme need to be paid, the scheme is probably more expensive than<br>
alternatives, if available. Or state differently; If you can do things yourself, it is always a cheaper option than let some<br>
others do things (under normal 'open market' rules and excluding the option of slavery :)).<br>
<br>
Nice read for some background:<br>
<br>
<a href="http://staff.um.edu.mt/carl.debono/DT_CCE3013_1.pdf" rel="noreferrer" target="_blank">http://staff.um.edu.mt/carl.debono/DT_CCE3013_1.pdf</a><br>
<br>
One has to note that in academia one often is in the situation that grants are obtained to buy hardware and that running costs<br>
(i.e. electricity and rack space) are matched by the university making the case of spending the grant money on paying amazone or<br>
google to do your 'compute' not so sensible if you can do things yourself. Also given the ease of deploying an HPC cluster<br>
nowadays with OpenHPC or something commercial like Qlustar or Bright, it will be hard pressed to justify long term bare metal<br>
cloud usage in these settings.<br>
<br>
Those were some technical and economical considerations that play a role in things. <br>
<br>
There is also another aspect when for example dealing with sensitive data you are to be helt responsible for. The Cloud model is<br>
not so friendly under those circumstances either. Again your data is put "on someone else's computer". Thinking of GDPR and<br>
such.<br>
<br>
So, back to the point, some 'user driven' workloads might end up on clouds or on bare-metal on-premisse clouds (seems to be the<br>
latest fad right now) but clearly not everything. Especially if the workloads are not 'user driven' but technology (or<br>
economically or socially driven) i.e. there is no other way of doing it except using some type of (specialized) technology (or<br>
it is just not allowed). I therefore also am of opinion that cloud computing is also not true (traditional) HPC and that the<br>
term HPC has been diluted over the year by commercial interest / marketing speak.<br>
<br>
BTW, on a side note / rant; The mathematics we are dealing with here are the constraints to be met in optimising things. The<br>
constraints actually determine the final optimal case (<a href="https://en.wikipedia.org/wiki/Lagrange_multiplier" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Lagrange_multiplier</a>) and people tend to<br>
'ignore' or not specify the constraints in their arguments about what is the best or optimal thing to do. So what I did here is<br>
I have given you some example of constraints (technical, economical and social) in the 'everything will be cloud' rhetoric to<br>
keep an eye on before drawing any conclusions about what the future might bring :). <br>
<br>
just my little opinion though...<br>
<br>
Disclaimer; I could be horribly wrong :).<br>
<br>
-- <br>
mark somers<br>
tel: +31715274437<br>
mail: <a href="mailto:m.somers@chem.leidenuniv.nl" target="_blank">m.somers@chem.leidenuniv.nl</a><br>
web:  <a href="http://theorchem.leidenuniv.nl/people/somers" rel="noreferrer" target="_blank">http://theorchem.leidenuniv.nl/people/somers</a><br>
_______________________________________________<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/listinfo/beowulf</a><br>
</blockquote></div>