<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 4:19 PM, Ivan Uemlianin <span dir="ltr"><<a href="mailto:ivan@llaisdy.com" target="_blank">ivan@llaisdy.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":bb" style="overflow:hidden"> <a href="http://jlouisramblings.blogspot.co.uk/2011/07/erlangs-parallelism-is-not-parallelism.html" target="_blank">http://jlouisramblings.<u></u>blogspot.co.uk/2011/07/<u></u>erlangs-parallelism-is-not-<u></u>parallelism.html</a></div>

</blockquote></div><br>As the author of that blog post, I would caution you to use Erlang for this kind of work.</div><div class="gmail_extra"><br></div><div class="gmail_extra">First, it is the kind of work where you have a small computational kernel which has to run as fast as possible. This is exactly the kind of problems where Erlang usually does not shine, due to the language being interpreted and not focused on fast floating point calculations. Erlang would be good as a higher-level coordinator in such systems, but the low-level code is probably better written in a compiled language with good FP performance: C, Common Lisp, Haskell, Ocaml, and so on.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Second, you would need to get to Infiniband from within Erlang. MPI and OpenMP already provides the tooling for this, so are you out to solve a problem, or are you curious and want to do research on how to make Erlang shine in this situation? NIFs are hard to pull off because you need to cooperate with the Erlang schedulers.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Third, the problems for which Erlang is best is different from your problem: providing low-latency stable operation even in the advent of spurious errors. And isolating bad code from good code [1].</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">[1] Aside: This is a strength of Erlang. A badly written process is usually not able to take down the node as a whole, due to memory space isolation. In large shared-memory-style programs, one bad library can easily sabotage the data on which another part of the program operates.</div>

</div>