# [erlang-questions] Distributing things

Fabio Mazanatti fabio.mazanatti@REDACTED
Sat Nov 7 21:55:15 CET 2009

```Hi,

the scenario I imagined for this exercise, based on Calum's text would be
something like assigning a range of numbers to each node, starting with the
lowest possible given by the entry parameter (the # of digits), controlling
its distribution and wrapping things up when a prime number is found by one
of the nodes.

An example: 4 nodes, generating a prime with 6 digits, would start at
100.000. The entry point would assign a range from 100.000 to 105.000 to
node 1, 105.001 to 110.000 to node 2, and so on. When a node finishes
traversing a range, a new block is assigned to it, until one of them returns
a valid value, and processing stops.

Maybe(?) this is a weird construction, but the idea is to explore parallel
processing of series, rather than disconected calls from many clients.

I'm new to Erlang too, just finished reading Joe's book (BTW, great work!!),
and am now exploring possibilities. Don't know if this matches with Calum's
idea, but it's something I would like to explore :-)

Cheers,
Fabio Mazanatti

On Sat, Nov 7, 2009 at 6:13 PM, Joe Armstrong <erlang@REDACTED> wrote:

> On Sat, Nov 7, 2009 at 7:53 PM, Calum <caluml@REDACTED> wrote:
> > Hello,
> >
> > I'm trying to get my head around Erlang, and I've decided to try to
> > take an existing program, and distribute it.
> > I'm using code from Joe's Erlang book which generates a prime of X
> > digits. On my laptop, anything over 500 digits takes a while.
> >
> > If you have one a single node running the code, it just loops,
> > calculates, tests if it's a prime, and increments the number, and
> > repeats if it's not a prime.
> > It's the "is_prime" test that seems to take the time, so that's the
> > part I want to distribute.
>
> Hang on - the algorithm just generates a random integer and tests if
> it is a prime,
> if it's not a prime it tries again. It has to generate many candidates
> before it finds a
> prime. Why not start N parallel processes each of which generates and
> tests candidates
> then when either one of them succeeds you can stop. Sounds easier to me.
>
> /Joe
>
>
> > I imagine if you have more than one node, you want to kick off "n"
> > is_prime tests, but of different values.
> >
> > What is the best way of going about this? Is it to kick off n, and
> > wait for all to return before kicking off another n? This isn't so
> > good if one of the nodes takes a very long time to return, as the rest
> > are doing nothing.
> > Or have a "global" "next value" variable, and each node just gets the
> > next one when it's finished its current one?
> > What would be the best way of maintaining this "next value" variable?
> >
> > How can I handle additional nodes "coming on line" as it's running?
> > How can I handle a node going offline in the middle of this?
> > Would you all just use the existing nodes() nodelist to do this, or
> > would you need to extend that in some way?
> >
> > Is there a good tried and tested method of deciding how to break down
> > a large job of 1000000 small jobs into batches for n nodes?
> >
> >
> > Hope these questions makes sense to you,
> >
> > C
> >
> > ________________________________________________________________
> > erlang-questions mailing list. See http://www.erlang.org/faq.html
> > erlang-questions (at) erlang.org
> >
> >
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
```