Interest?

[Greg Zuro]

Is there some concept of the support that there will be for Erlang (Elixir!) on this board?

I have Erlang running easily on the Zedboard, so expect that it will run fine on the ARM in this board, so how might Erlang practicaly extend to the Epiphany portion?

Cheers,
Greg

[sr-ix]

While I'm still waiting on my board, I've been working with Erlang little over a year now (started from a previous job in VoIP/telephony) and went through the very awesome training from Erlang Solutions by Robert Virding.

[shr]

The distribution already runs on the Parallella board though one has to implement Epiphany functionality in C/C++/OpenCL. I think that 2MB is the practical lower limit to run the current Erlang VM so running a VM on each node wouldn't work with the current Epiphany chips.

Perhaps the VM could be factored into pieces that work on the Epiphany. The is working to scale Erlang to thousands of distributed cores and some of this work may be applicable to Epiphany.

[alexrp]

The trick to porting something like Erlang to Epiphany is to run most of the VM on the host CPU and only the actual bytecode interpretation as a small C executable on the accelerator side. The host then uses the various core reset functionality to swap out processes as it sees fit.

And the problem with the above is that this is not how the current Erlang VM works at all. :(

[shr]

So, how hard would it be to factor the byte code interpreter out of the VM as a whole? How big might it be?

[greytery]

Running compute intensive code on an interpreted layer on a coprocessor does seem to be a v. inefficient approach, by definition. I think that supports the point of trying to run the Erlang VM on the ARM, and only a v.small subset on the Epiphany - IF AT ALL!

As said above, Erlang processes can make calls to C/C++ routines, and sometimes that's the best way.
For example, I'm thinking about Wings 3D (Erlang) and how it accelerates some of its graphics calcs (C++, OpenGL). That is, it keeps a healthy distinction between the main program body running on general purpose X86, and making best use of the co-processor (i.e the graphics card).

So instead of trying to run a cut-down VM on each core, why not concentrate on ensuring that there are efficient mechanisms and interfaces to invoke Epiphany routines? Methinks it would be simpler than gutting the VM and deliver immediate value.

Use Erlang for what it does best (e.g. distributed scalability and resilient computing) and the Epiphany (or any other coprocessor) for what it does best.

I have - sorry, have ordered - two boards, and one project I have in mind is to run Erlang on my Windows PCs AND on the Parallellas, so distributing the processes across my Gigabyte network. Only the processes that required specific acceleration would need to run on the Parallellas.

(Edit) Gigabit. I Wish!

[shr]

The practicality of running interpreted code on the Epiphany depends upon how much work each interpreted insturction does. If the instruction is 'A + B' where A and B are large matrices it can look quite practical. As things stand now using Erlang on the ARM cores for high level coordination and control and calling C/C++/OpenCL computational kernels on the Epiphany for specicalized tasks is best.

[alexrp]

[Greg Zuro]

[shr]

The Xen effort doesn't look applicable for Parallella to me. It's more about removing the traditioal OS and running Erlang directly on the Xen hypervisor. looks like a good starting point perhaps treating the Epiphany as a collection of virtual devices.