<div class="gmail_extra">On Sun, Nov 4, 2012 at 11:21 PM, Bryce Lelbach <span dir="ltr"><<a href="mailto:blelbach@cct.lsu.edu" target="_blank">blelbach@cct.lsu.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":20q">HPX is drastically different from MPI. Comparison table:<br>
<br>
HPX: Intra-node (threading) and inter-node (distributed); provides extermely fine grained threading (millions of short-lived threads per node)<br>
MPI: Only does distributed.<br></div></blockquote><div><br></div><div>Uh, MPI does intra-node. In fact, the main reason for explicit threads within a node is specifically to enhance sharing, mostly cache. There are viable solutions to network device contention, including explicitly via subcomms and implicitly via lighter weight MPI ranks (e.g., AMPI).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":20q">
<br>
HPX: Sends work to data.<br>
MPI: Sends data to work.<br></div></blockquote><div><br></div><div>Uh, you run whatever task you want on the data at hand. You _can_ send data, but that is in no way dictated by the MPI model.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":20q">
<br>
HPX: Provides an active global address space to abstract local memory boundaries across nodes.<br>
MPI: Forces user code to explicitly perform remote communication.<br></div></blockquote><div><br></div><div>This is why we have libraries. The utility of a global address space is mostly a philosophical debate. That remote data must be copied to local storage if it will be accessed frequently is not controversial.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":20q">
<br>
HPX: Hides latencies by overlapping them with out computations.<br>
MPI: Only option to deal with latencies is latency avoidance.<br>
<br>
HPX: Utilizes local synchronization and zealously avoids explicit global barriers, allowing computation to proceed as far as possible without communicating/synchronizing.<br>
MPI: Strongly emphasizes global barriers.<br></div></blockquote><div><br></div><div>Bullshit. An explicit barrier (like MPI_Barrier) is almost never necessary or desirable. Indeed, it implies side-channel synchronization, such as via the file system. Reductions like MPI_Allreduce() represent a data dependence with no opportunity for further local work in the majority of existing algorithms, such as Krylov methods and convergence tests. We have a number of new algorithms, such as pipelined GMRES, for which non-blocking collectives (MPI_Iallreduce, MPI_Ibarrier) are important.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":20q">
<br>
HPX: Supports the transmission of POD data, polymorphic types, functions and higher order functions (e.g. functions with bound arguments, etc).<br>
MPI: Only does POD data.<br></div></blockquote><div><br></div><div>MPI_Datatypes are much more general.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":20q">
<br>
HPX: Diverse set of runtime services (builtin, intrinsic instrumentation, error handling facilities, logging, runtime configuration, loadable modules).<br>
MPI: None of the above.<br>
<br>
HPX: Supports dynamic, heuristic load balancing (both at the intra-node and inter-node level).<br>
MPI: Limited builtin support for static load balancing.<br>
<br>
HPX is a general-purpose C++11 runtime system for parallel and distributed computing<br>
of any scale (from quad-core tablets to exascale systems). It is freely available<br>
under a BSD-style license, and developed by a growing community of international<br>
collobators. It is an integral part of US DoE's exascale software stack, and is<br>
supported heavily by the US NSF.<br>
<br>
<a href="http://stellar.cct.lsu.edu" target="_blank">stellar.cct.lsu.edu</a> for benchmarks, papers and links to the github repository.</div></blockquote></div><br></div><div class="gmail_extra">I wish you the best in this project, but frankly, I'm unimpressed by the performance obtained in your papers and it appears that this project has overlooked many of the same "library" features that GASNet and other PGAS systems have missed.</div>