<div dir="ltr"><div dir="ltr">On Wed, Oct 14, 2020 at 1:24 PM Michael Di Domenico <<a href="mailto:mdidomenico4@gmail.com">mdidomenico4@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Oct 14, 2020 at 11:53 AM Oddo Da <<a href="mailto:oddodaoddo@gmail.com" target="_blank">oddodaoddo@gmail.com</a>> wrote:<br>
> I did not use Spark or Scala as measures of greatness but they are evolution, at least people are trying ;). Not all evolution is in the positive direction, of course. But I do think that the world of software engineering has moved/changed for better since 1990s. Yes, we built software just fine in the 1990s and we built it fine in the 1960s but that is like saying we drove cars just fine in the 1930s, why do we need new cars.<br>
<br>
I don't see it that way.  to me things like hadoop/Spark/etc were<br>
designed to solve a specific problem other paradigms couldn't (or<br>
rather shouldn't).  it's not evolutionary, it's something new.  your<br></blockquote><div><br></div><div>You stated that Spark/Hadoop approach can code for everything that MPI can code for and vice versa. If this is all true and it is that easy, nobody would have "invented" them since we already had MPI/C/C++ to solve all our problems ;-). Yet, I think it was the absence of technical debt or maybe investment is a better term - to describe why people went with a particular approach. First it was Hadoop and then Spark, Akka, kafka and all of the surrounding ecosystem, including new languages to facilitate this innovation.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">i'll agree that in some respects software engineering has gotten<br>
better in the last 20yrs, but it's subjective.  there are a lot of<br>
things that have gotten better and there are a lot of things that are<br>
much worse.  but i'm not sure you can apply that statement to HPC.<br>
HPC code doesn't churn like business code or even more volatile cloud<br>
code.  HPC code is usually written to solve something specific and<br>
gets incremental updates over time.  usually that something specific<br>
hasn't changed the last 20yrs (think physics/chemistry) the models we<br>
use to describe or solve the problems likely have, but the underlying<br>
code is probably basically the same with tweaks along the way to fit<br>
the new model.<br></blockquote><div><br></div><div>I disagree. I think yes, there is old code that does not churn but there are always new people/grad students coming into the field. They too are being pointed in the same direction of how to do things, which is what we are discussing here ;-)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">an evolution to MPI.  but it goes back to technical debt.  to re-write<br>
something in chapel is non-trivial and may not be worth the time.<br>
writing something new and choosing chapel is really left up to the<br>
developer.  i have some chapel users here and there, but they're a<br>
minority.  and since chapel is largely only found on cray machines its<br>
exposure is low<br></blockquote><div><br></div><div>It seems that in your world nothing new ever gets written? You are talking only about re-writes ;).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
i'm not sure the philosophical debate you're looking for is one that<br>
can take place.  like vim vs emacs or init5 vs systemd.  everything<br>
exists and it usually boils down to personal choice.  i run a fairly<br></blockquote><div><br></div><div>OK, this is another contribution I appreciate. So far I have "technical investment", "lack of motivation" and "personal preference". I came here trying to figure out what it is that makes or breaks these things - I appreciate you taking the time!</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
large hpc center and "user written" C/MPI code really only represents<br>
<20% of my workload.  but that's subjective.  i'd bet if the beowulf<br>
list did a poll you'd find heavy slants based on user base.  if you<br>
feel the industry hasn't moved, maybe thats just where you are<br>
working, what you're doing, or who you're working with rather than a<br>
representation of the hpc industry.<br></blockquote><div><br></div><div>This is probably true. What is the rest of the 80% of the load in your HPC world?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
i still think you're trying to compare two things that shouldn't be<br>
compared.  MPI isn't a programming language, it's a library.  if you<br>
want to debate programming language evolution, that's a totally<br>
separate discussion from one that includes MPI/Spark/Etc<br></blockquote><div><br></div><div>Programming languages are a part of it and I have said this before - languages like Julia can incorporate MPI as an underlying (or one of underlying) mechanisms/libraries to distribute computation. I have nothing against MPI (as I have stated before). I have something - curiosity - about what is holding a field in a certain state. Spark is a framework but I think it is much more than MPI, by the way - as it is both a way to distribute computation, but there is also lazy evaluation, resilient datasets, Scala, functional programming etc.<br></div></div></div>