<div dir="ltr">Doug, thank you for taking the time! Your Julia comments are in line with my impression of it, hence the initial question I posed in this thread. Thank you for all your insights.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020 at 5:03 PM Douglas Eadline <<a href="mailto:deadline@eadline.org">deadline@eadline.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Tue, Oct 13, 2020 at 3:54 PM Douglas Eadline <<a href="mailto:deadline@eadline.org" target="_blank">deadline@eadline.org</a>><br>
> wrote:<br>
><br>
>><br>
>> It really depends on what you need to do with Hadoop or Spark.<br>
>> IMO many organizations don't have enough data to justify<br>
>> standing up a 16-24 node cluster system with a PB of HDFS.<br>
>><br>
><br>
> Excellent. If I understand what you are saying, there is simply no demand<br>
> to mix technologies, esp. in the academic world. OK. In your opinion and<br>
> independent of Spark/HDFS discussion, why are we still only on openMPI in<br>
> the world of writing distributed code on HPC clusters? Why is there<br>
> nothing<br>
> else gaining any significant traction? No innovation in exposing higher<br>
> level abstractions and hiding the details and making it easier to write<br>
> correct code that is easier to reason about and does not burden the writer<br>
> with too much of a low level detail. Is it just the amount of investment<br>
> in<br>
> an existing knowledge base? Is it that there is nothing out there to<br>
> compel<br>
> people to spend the time on it to learn it? Or is there nothing there? Or<br>
> maybe there is and I am just blissfully unaware? :)<br>
><br>
<br>
<br>
I have been involved in HPC and parallel computing since the 1980's<br>
Prior to MPI every vendor had a message passing library. Initially<br>
PVM (Parallel Virtual Machine) from Oak Ridge was developed so there<br>
would be some standard API to create parallel codes. It worked well<br>
but needed more. MPI was developed so parallel hardware vendors<br>
(not many back then) could standardize on a messaging framework<br>
for HPC. Since then, not a lot has pushed the needle forward.<br>
<br>
Of course there are things like OpenMP, but these are not distributed<br>
tools.<br>
<br>
Another issue the difference between "concurrent code" and<br>
parallel execution. Not everything that is concurrent needs<br>
to be executed in parallel and indeed, depending on<br>
the hardware environment you are targeting, these decisions<br>
may change. And, it is not something you can figure out by<br>
looking at the code.<br>
P<br>
arallel computing is hard problem and no one has<br>
really come up with a general purpose way to write software.<br>
MPI works, however I still consider it a "parallel machine code"<br>
that requires some careful programming.<br>
<br>
The good news is most of the popular HPC applications<br>
have been ported and will run using MPI (as best as their algorithm<br>
allows) So from an end user perspective, most everything<br>
works. Of course there could be more applications ported<br>
to MPI but it all depends. Maybe end users can get enough<br>
performance with a CUDA version and some GPUs or an<br>
OpenMP version on a 64-core server.<br>
<br>
Thus the incentive is not really there. There is no huge financial<br>
push behind HPC software tools like there is with data analytics.<br>
<br>
Personally, I like Julia and believe it is the best new language<br>
to enter technical computing. One of the issues it addresses is<br>
the two language problem. The first cut of something is often written<br>
in Python, then if it get to production and is slow and does<br>
not have an easy parallel pathway (local multi-core or distributed)<br>
Then the code is rewritten in C/C++ or Fortran with MPI, CUDA, OpenMP<br>
<br>
Julia is fast out the box and provides a growth path for<br>
parallel growth. One version with no need to rewrite.  Plus,<br>
it has something called "multiple dispatch" that provides<br>
unprecedented code flexibility and portability. (too long a<br>
discussion for this email) Basically it keeps the end user closer<br>
to their "problem" and further away from the hardware minutia.<br>
<br>
That is enough for now. I'm sure others have opinions worth<br>
hearing.<br>
<br>
<br>
--<br>
Doug<br>
<br>
<br>
<br>
> Thanks!<br>
><br>
<br>
<br>
-- <br>
Doug<br>
<br>
</blockquote></div>