On Friday 09 May 2008 19:17:30 Ulf Wiger wrote: > Jon Harrop skrev: > > On Friday 09 May 2008 14:00:52 you wrote: > >> Jon Harrop skrev: > >>> . Parallelism is for performance and performance > >>> > >> > requires mutable data structures. > >> > >> I disagree. SMP Erlang has no mutable data structures, > >> but achieves very good scalability anyway. > > > > Scalability != performance. For CPU intensive tasks, > > > > Erlang is uniformly slow. > > I don't see how you can say that. If you introduce the > restriction that there can be only one CPU, then this > might be true.
On 1 CPU Erlang is currently ~5x slower in this context. So even if we ignore the cost of message passing we know Erlang cannot be competitive for <6 cores. In fact, you find that the cost of message passing over mutation makes Erlang not competitive for any existing computers in this context, even 256 CPU shared memory supercomputers. This is why Erlang has not (and will not) penetrate the market of scientists programming shared memory supercomputers. For the same reason, Erlang is not relevant for exploiting multicore: its remit is massive concurrency which is a completely different problem. The theoretical scaling of Erlang's performance in terms of asymptotic complexity is irrelevant because we're still looking at small numbers (<<256) of cores and the prefactor is huge. Moreover, this will never change: even when we have 1,024-core machines there will still be locality effects best exploited by sharing memory between physically-close cores. So neither approach is a panacea but concurrent GC is essential now and message passing will be essential in 10 years. > Some applications are very difficult to > scale to multiple CPUs, but others are inherently > scalable. For some problems, mutable data structures > make all the difference, and in others, they just make > a mess of things. > > If you say "parallelism is for performance", you imply > that the program is scalable, and that it actually makes > a difference to add more CPUs. In this case, mutable > the presence of data structures will make scaling more > difficult. That is commonly claimed by the proponents of alternative approaches (purity, STM, message passing etc.) but I have found it to be untrue in the case of F# although I can believe it applies when there is uncontrolled mutation. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
