[erlang-questions] first erlang program

[Steve Davis]

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
primes2(Max) ->
    sieve(2, Max, []).

sieve(X, Max, Acc) when X =< Max ->
    case is_prime(X, Acc) of
    true ->
        Acc0 = [X|Acc];
    false ->
        Acc0 = Acc
    end,
    sieve(X + 1, Max, Acc0);
sieve(_, _, Acc) ->
    lists:reverse(Acc).

is_prime(X, [H|_]) when X rem H =:= 0 ->
    false;
is_prime(X, [_|T]) ->
    is_prime(X, T);
is_prime(_, []) ->
    true.

So maybe the sieve would work as a demo after all, by distributing the 
prime sieves across multiple nodes using spawn(Node, Fun).

/s

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.
>
> best,
> /s
>
> 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" 
>> code.
>>
>> 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.
>>
>> regs,
>> /s
>>
>> On Saturday, January 5, 2013 9:16:30 PM UTC-6, rusi wrote:
>>>
>>> On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis <steven.cha...@REDACTED>wrote:
>>>
>>>> And... for fun... a refactored version that should scale and also avoid 
>>>> io:format:
>>>>
>>>
>>> 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 
>>> cable.
>>> 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...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130106/3985f657/attachment.htm>