[erlang-questions] first erlang program
Sun Jan 6 13:44:55 CET 2013
Something interesting. I imagined that a serial implementation of this
algorithm would be as fast/faster than the concurrent version. So I quickly
ran up a comparison.
On measuring, I found that I my first guess was wrong. The parallel version
is some 30-50% quicker...
%% serial code used to compare
sieve(2, Max, ).
sieve(X, Max, Acc) when X =< Max ->
case is_prime(X, Acc) of
Acc0 = [X|Acc];
Acc0 = Acc
sieve(X + 1, Max, Acc0);
sieve(_, _, Acc) ->
is_prime(X, [H|_]) when X rem H =:= 0 ->
is_prime(X, [_|T]) ->
is_prime(_, ) ->
So maybe the sieve would work as a demo after all, by distributing the
prime sieves across multiple nodes using spawn(Node, Fun).
On Sunday, January 6, 2013 6:02:06 AM UTC-6, Steve Davis wrote:
> I'm going to rebut my previous post!
> Whenever I'm creating a useful application I now "naturally" resort to
> using OTP support, but it's not strictly necessary. In fact, if you are
> learning it may not be very productive to introduce too many parts of the
> platform in one go. The next thing to understand is actually just nodes and
> node communication in the core erlang modules.
> Secondly, I'm not sure the sieve is a good candidate for an algorithm to
> distribute since the outcome of each calculation is reliant on all previous
> calculations. You may consider a different program that has parts that can
> be obviously partitioned out into independent blocks of processing.
> On Sunday, January 6, 2013 5:44:27 AM UTC-6, Steve Davis wrote:
>> Hm ok. By "throw in more hardware" you are meaning you wish to take
>> advantage of distribution as well as concurrency. Perhaps I should have
>> been more specific about the context of scaling I was talking about,
>> namely, vertical. You see, while this version of the program should be able
>> to use all the cores (which without more work, I don't guarantee), and
>> won't exhaust resources (which is easy to prove), it also won't (and was
>> not designed to) distribute across nodes.
>> For that, the next step is that you need to turn eratos into a gen server
>> inside an OTP application... You will need to consider in the next
>> iteration of design what parts of the processing you are distributing, what
>> messages need to be passed between distributed nodes. This may mean some
>> thought about how elements of the algorithm can be separated
>> efficiently. For all the "magic" of OTP, you will likely find that what
>> erlang is rather good at is facing you with the real problem you are trying
>> to solve rather than to allowing you to get distracted inside "boilerplate"
>> When I started learning the many capabilities of Erlang, I found that as
>> well as the documentation's manuals, Joe's book was the most helpful guide
>> for me... http://pragprog.com/book/jaerlang/programming-erlang (which
>> IIRC may be being updated to a new edition as I write) BTW this is not to
>> deny the quality of other books on Erlang (e.g. I have not read LYSE), but
>> rather that Joe's book happened to fit my approach to learning.
>> On Saturday, January 5, 2013 9:16:30 PM UTC-6, rusi wrote:
>>> On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis <>wrote:
>>>> And... for fun... a refactored version that should scale and also avoid
>>> Thanks Steve for your efforts.
>>> Now if I wanted to 'see' the scaling what do I have to do/setup?
>>> Just for context: I am demoing this to a class of noobs (more noob than
>>> me if thats possible :D) on a 4-core laptop mostly on linux but could also
>>> use windows.
>>> I suppose I could hook up another machine with a back-to-back ethernet
>>> Naturally I would prefer to 'scale up the scaling-up measurement'
>>> ie first erlang-ecosystem methods
>>> then linux processes methods
>>> then throwing more 'hard' hardware
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions