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
On Sat, Jun 2, 2012 at 7:24 PM, Matthew Evans <mattevans...@hotmail.com> wrote:
> 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.
> On Sat, Jun 2, 2012 at 7:24 PM, Matthew Evans <mattevans...@hotmail.com>
> wrote:
> > 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.
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.
On 3 June 2012 02:30, Björn-Egil Dahlberg <wallentin.dahlb...@gmail.com>wrote:
> After that reminder I felt I had to write a README.
> *commit, push*
> There, I fixed it.
>> On Sat, Jun 2, 2012 at 7:24 PM, Matthew Evans <mattevans...@hotmail.com>
>> wrote:
>> > 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.
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
On 03/06/2012, at 06.41, Anoop Thomas Mathew <atm...@gmail.com> wrote:
> 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.
> On 3 June 2012 02:30, Björn-Egil Dahlberg <wallentin.dahlb...@gmail.com> wrote:
> After that reminder I felt I had to write a README.
> *commit, push*
> There, I fixed it.
> On Sat, Jun 2, 2012 at 7:24 PM, Matthew Evans <mattevans...@hotmail.com> wrote:
> > 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.
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.
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)
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:
> 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)
> 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:
> 2012/6/3 Ivan Uemlianin <i...@llaisdy.com>:
>> 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)
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:
(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?
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...
> 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:
> (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?
