Re: [Caml-list] Re: Why OCaml sucks

[Jon Harrop <jon@ffconsultancy.com>]

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