<div dir="ltr">Sorry for the fancy words... for my lack of analogies. <div><br></div><div>Data processing in HPC requires solving the CAP puzzle (or CAP theorem). You might be interested in my SC15 workshop talk that addressed both compute and data intensive HPC: <a href="https://www.researchgate.net/publication/285579006_Solving_the_Scalability_Challenge_from_the_Ground_Up">https://www.researchgate.net/publication/285579006_Solving_the_Scalability_Challenge_from_the_Ground_Up</a></div><div><br></div><div>An older version of the source is open at this link: <a href="https://github.com/jys673/Synergy30">https://github.com/jys673/Synergy30</a></div><div><br></div><div>This version has a dynamic daemon generation technique suitable for running smaller experiments in traditional HPC clusters and HPC clouds.</div><div><br></div><div>A new version is still under development. I am looking for serious collaborators for both legacy HPC code re-engineering and data intensive HPC challenges. We are looking at the new TACC challenges. If you are interested, we can talk.</div><div><br></div><div>Justin</div><div>SERC310</div><div><br></div><div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 7:15 PM, C Bergström <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Mar 7, 2016 at 5:58 AM, Justin Y. Shi <<a href="mailto:shi@temple.edu">shi@temple.edu</a>> wrote:<br>
> Peter:<br>
><br>
> Thanks for the questions.<br>
><br>
> The impossibility was theoretically proved that it is impossible to<br>
> implement reliable communication in the face of [either sender or receiver]<br>
> crashes.  Therefore, any parallel or distributed computing API that will<br>
> force the runtime system to generate fixed program-processor assignments are<br>
> theoretically incorrect. This answer is also related to your second<br>
> question: the impossibility means 100% reliable communication is impossible.<br>
><br>
> Ironically, 100% reliable packet transmission is theoretically and<br>
> practically possible as proved by John and Nancy for John's dissertation.<br>
> These two seemingly conflicting results are in fact complementary. They<br>
> basically say that distributed and parallel application programming cannot<br>
> rely on the reliable packet transmission as all of our current distributed<br>
> and parallel programming APIs assume.<br>
><br>
> Thus, MPI cannot be cost-ineffective in proportion to reliability, because<br>
> of the impossibility. The same applies to all other APIs that allows direct<br>
> program-program communications. We have found that the <key, value> APIs are<br>
> the only exceptions for they allow the runtime system to generate dynamic<br>
> program-device bindings, such as Hadoop and Spark. To solve the problem<br>
> completely, the application programming logic must include the correct<br>
> retransmission discipline. I call this Statistic Multiplexed Computing or<br>
> SMC. The Hadoop and Spark implementations did not go this far. If we do<br>
> complete the paradigm shift, then there will be no single point failure<br>
> regardless how the application scales. This claim covers all computing and<br>
> communication devices. This is the ultimate extreme scale computing<br>
> paradigm.<br>
><br>
> These answers are rooted in the statistic multiplexing protocol research<br>
> (packet switching). They have been proven in theory and practice that 100%<br>
> reliable and scalable communications are indeed possible. Since all HPC<br>
> applications must deploy large number of computing units via some sort of<br>
> interconnect (HP's The Machine may be the only exception), the only correct<br>
> API for extreme scale HPC is the ones that allow for complete<br>
> program-processor decoupling at runtime. Even the HP machine will benefit<br>
> from this research. Please note that the 100% reliability is conditioned by<br>
> the availability of the "minimal viable set of resources". In computing and<br>
> communication, the minimal set size is 1 for every critical path.<br>
><br>
> My critics argued that there is no way statistic multiplexed computing<br>
> runtime can compete against bare metal programs, such as MPI. We have<br>
> evidences to prove the opposite. In fact SMC runtime allows dynamic<br>
> adjustments of processing granularity without reprogramming. Not only we can<br>
> prove faster performances using heterogeneous processor but also homogeneous<br>
> processors. We see this capability is critical for extracting efficiency out<br>
> of HPC clouds.<br>
<br>
</div></div>I always get lost in the fancy words of research papers - Is the<br>
source to any of this open? How could just a normal guy like me<br>
reproduce or independently verify your results?<br>
<br>
I'm not sure at what level you're talking sometimes - at the network<br>
level we have things like TCP (instead of UDP) when it comes to<br>
ensuring that packet level reliability is ensured - at a data level<br>
you have ACID compliant databases for storage.. there are lots of<br>
technology on the "web" side which are commonly used and required<br>
since the "internet" is inherently unstable/unreliable. In my mind<br>
"exascale" machines will need to be programmed with a more open view<br>
of what is or isn't. Should we continue to model everything around the<br>
communication or switch focus to more of resolving data dependencies<br>
and locality..<br>
</blockquote></div><br></div>