[erlang-questions] A visual tour of Erlang

[Matthew Evans]

Sorry if this is a repost. This was posted on Reddit. Although it probably doesn't have any "real" uses (yet) I think it's a very nice way to model an Erlang VM and your applications.

It got praise from our Java developers when I ran it on our Erlang application at work.

Cudos to Kresten Krab for writing this application.

https://www.youtube.com/watch?v=lHoWfeNuAN8

https://github.com/krestenkrab/erlubi

[Lukas Larsson]

If you find that useful you might want to checkout
https://github.com/psyeugenic/fgraph as well.

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Björn-Egil Dahlberg]

2012/6/2 Lukas Larsson <lu...@erlang-solutions.com>

If you find that useful you might want to checkout
https://github.com/psyeugenic/fgraph as well.

After that reminder I felt I had to write a README.

*commit, push*

There, I fixed it. 

[Anoop Thomas Mathew]

Hi All,

That was a cool video demonstration of erlang processes. Nice work. Kudos to Kresten Krab.

It aroused a question in me that, isn't erlang creating way too many processes, and why is that so?

If someone can spread some light into this topic, and give a comprehensive explanation about HOW and WHY, that would be great.

Thanks,

Anoop Thomas Mathew

atm
___
Life is short, Live it hard.

[Torben Hoffmann]

Hi Anoop,

Erlang has its own VM, so all those processes are very lightweight compared to OS processes. 

The basic unit of computation in Erlang is a process with its own memory space and you can only communicate with a process by sending it a message.  

This set-up is necessary if you want to build a fault tolerant system - the last ingredience is the ability to link and monitor processes. Two linked processes will die if either of them dies. A monitor will be notified if the process it monitors die. 

These simple mechanisms is what allows Erlang to work so well. 

Hope this clarifies things a bit for you. 

Cheers,

Torben

Sent from my iPhone

[Ulf Wiger]

On 3 Jun 2012, at 06:41, Anoop Thomas Mathew wrote:

It aroused a question in me that, isn't erlang creating way too many processes, and why is that so?

There is such a thing as too many processes - and too few.

The key thing about a process is that it is a single thread of control.

If you try to handle multiple, interdependent and interleaving tasks

in one single thread of control, bad things tend to happen, just as

it tends to do when one human being tries to handle too many things

at the same time.

But many threads of control need managing/coordination. Just as

human organizations become unwieldy when there are more people

than the problem calls for, too many processes in a concurrency-

oriented program tends to become a problem in itself.

The trick, then, is to figure out how many processes the problem calls

for, and to use that many - no more, no less.

Drawing inspiration from how people solve coordination problems,

including how people deal with uncertainty and inconsistencies,

can be a great help when programming Erlang.

BR,

Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.

http://feuerlabs.com

[Ivan Uemlianin]

On 3 Jun 2012, at 10:11, Ulf Wiger <u...@feuerlabs.com> wrote:

> Drawing inspiration from how people solve coordination problems,
> including how people deal with uncertainty and inconsistencies,
> can be a great help when programming Erlang.

Very good suggestion.

What do they know of Erlang, who only Erlang know? (with apologies to Kipling)

Ivan

[Emilio De Camargo Francesquini]

Hello,

About a month ago I wrote something similar to be able to "see", not
the links/monitors/genealogy of the Erlang processes, but rater the
communication graph between them. For this particular example the
internal graph of communication of CouchDB.

If there is interest I can upload the code to Github...

This video shows the processes communication graph for CouchDB running
in a machine with 24-cores. CouchDB was exercised using YCSB and the
video was generated using Ubigraph. I've posted the video here:

http://www.youtube.com/watch?v=2MO6Uv7KZ7g

Regards,

Emilio

2012/6/3 Ivan Uemlianin <iv...@llaisdy.com>:

[Adrian Roe]

Awesome video. I'd definitely be interested in the code behind it.

Adrian

Sent from my iPhone

[Zabrane Mickael]

Hi Emilio,

For sure there is an interest.

 

On Jun 5, 2012, at 2:25 PM, Emilio De Camargo Francesquini wrote:

http://www.youtube.com/watch?v=2MO6Uv7KZ7g

Well done.

Regards,

Zabrane

[Richard O'Keefe]

On 6/06/2012, at 12:25 AM, Emilio De Camargo Francesquini wrote:
> This video shows the processes communication graph for CouchDB running
> in a machine with 24-cores. CouchDB was exercised using YCSB and the
> video was generated using Ubigraph. I've posted the video here:
>
> http://www.youtube.com/watch?v=2MO6Uv7KZ7g

(a) When you say "communication graph" what actually do you mean?
(b) What does it signify in the movie when nodes go shooting away
from th core and disappear off-screen?

[Emilio De Camargo Francesquini]

Hello Richard,

a) For each message sent inside the VM there is an edge in the graph
representing it. As the number of messages is huge and the processes
that send these messages are being created and destroyed all the time,
the edges "decay" after a few seconds and are removed from the graph.
When a vertex is no longer connected to any other vertex, that is, it
has no connected edges, it is removed from the animation. So in fact
the graph represents the processes and the messages exchanged between
them during the execution of CouchDB. This is what I called
communication graph.

b) The shooting away, as you call it, is just a side-effect of the
algorithm used to draw the graph. It is a force-directed layout, so
when the last edge is disconnected from the vertex it gets "repelled"
from the rest of the vertices, and as soon as it has no edges
connected to it, it gets removed from the animation. The actual
execution speed is 8X faster than it is shown in the video.

For those interested in the code, I'll try to upload the code
somewhere until the end of this week...

Best Regards

Emilio

2012/6/6 Richard O'Keefe <o...@cs.otago.ac.nz>: