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.<div><br></div><div>On measuring, I found that I my first guess was wrong. The parallel version is some 30-50% quicker... <div><div>%% serial code used to compare</div><div>primes2(Max) -></div><div>    sieve(2, Max, []).</div><div><br></div><div>sieve(X, Max, Acc) when X =< Max -></div><div>    case is_prime(X, Acc) of</div><div>    true -></div><div>        Acc0 = [X|Acc];</div><div>    false -></div><div>        Acc0 = Acc</div><div>    end,</div><div>    sieve(X + 1, Max, Acc0);</div><div>sieve(_, _, Acc) -></div><div>    lists:reverse(Acc).</div><div><br></div><div>is_prime(X, [H|_]) when X rem H =:= 0 -></div><div>    false;</div><div>is_prime(X, [_|T]) -></div><div>    is_prime(X, T);</div><div>is_prime(_, []) -></div><div>    true.</div><div><br></div><div>So maybe the sieve would work as a demo after all, by distributing the prime sieves across multiple nodes using spawn(Node, Fun).</div><div><br></div><div>/s</div><br>On Sunday, January 6, 2013 6:02:06 AM UTC-6, Steve Davis wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'm going to rebut my previous post!<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>best,</div><div>/s</div><div><br>On Sunday, January 6, 2013 5:44:27 AM UTC-6, Steve Davis wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div><br></div><div>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.</div><div><br></div><div>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... <a href="http://pragprog.com/book/jaerlang/programming-erlang" target="_blank">http://pragprog.com/<wbr>book/jaerlang/programming-<wbr>erlang</a> (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.</div><div><br></div><div>regs,</div><div>/s</div><div><div><div><br>On Saturday, January 5, 2013 9:16:30 PM UTC-6, rusi wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Jan 5, 2013 at 9:13 PM, Steve Davis <span dir="ltr"><<a>steven.cha...@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

And... for fun... a refactored version that should scale and also avoid io:format:<br>
</blockquote></div><br>Thanks Steve for your efforts.<br>Now if I wanted to 'see' the scaling what do I have to do/setup?<br><br>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.<br>
<br>I suppose I could hook up another machine with a back-to-back ethernet cable.<br>Naturally I would prefer to 'scale up the scaling-up measurement'<br>ie first erlang-ecosystem methods<br>then linux processes methods<br>
then throwing more 'hard' hardware<br>
</blockquote></div></div></div></blockquote></div></blockquote></div></div>