Jon Harrop skrev:
On Saturday 10 May 2008 15:51:20 Ulf Wiger wrote:
Jon Harrop skrev:
So we agree that Erlang is not in the same league
> as OCaml for CPU-intensive tasks on <6 cores?
For compute-intensive tasks that don't require coordination
with other tasks, sure.
I specifically said "For CPU intensive tasks...".
> I was not making a "sweeping general statement".
Perhaps we simply read different things into the word
"CPU-intensive". If a program is able to make full use
of the CPU and is limited by available CPU capacity,
I will call it CPU-intensive.
In another post you compared an F# program with an
OCaml program, where the OCaml program had to do
marshaling and unmarshaling in order to achieve
cooperation between tasks. This is of course also
CPU-intensive, and if a significant amount of this
is required, OCaml will lose against Erlang big time,
just as it did against F#.
In the specific context of your products, yes. Few
> general programs require a high degree of
> concurrency though.
One of the things you quickly notice when programming
in a language that really encourages you to explore
the concurrency patterns in your problem, is that
there is much more concurrency than you'd think, even
in conventional programs.
It's just that we've grown so accustomed to mapping
problems onto a sequential model, simply because
dealing with concurrency is a nightmare in most
conventional programming languages.
Here's another way of looking at it: While programming
so far has been very much about automating singleton tasks
that would otherwise take a long time to perform manually
(e.g. scientific computing), there is a huge number of
problems that are normally solved by groups of people
cooperating. These can be automated too, but without
mirroring the concurrency patterns used by people when
solving these problems manually, it gets very difficult.
We'll see a great number of web-based applications where
you not only need to handle hundreds or thousands of
simultaneous visitors, but each session will require
(real-time) interaction with other systems, as well as
perhaps other sessions within the system.
I think the term "massive concurrency" tends to lead to
misunderstandings. The key characteristic of a concurrency-
oriented language is that it's so easy and cheap to create
processes and coordinate between tasks, that you don't
think twice about creating just as many processes as you
need in order to solve the problem neatly. If this means
creating 10,000 processes, that shouldn't be an issue, just
like creating 10,000 objects shouldn't be for an OO language.
But to fully utilize 4 or 8 cores, you don't need thousands
of processes.
>> but jumping out of
the shared memory space and executing the code in something
like C or OCaml, we pay so much for heavyweight
communication that it's usually not worth the effort - never
mind the fact that debugging becomes much, much harder.
Perhaps. Comparing debugging is apples and oranges though.
I simply meant that combining different languages and
execution environments makes debugging much more difficult
than using just one.
So on total system performance, we usually do very well,
even though it is pretty slow on some specific parts of
the problem. And we get superior robustness and
maintenance cost, which for our customers is far more
important than raw performance.
I don't doubt that but I do not believe that Erlang's success
> with massively concurrent applications has anything to do
> with adding better multicore support to OCaml.
I agree that this is something very different from trying to
speed up scientific calculations using shared-memory
parallelism. But I would encourage a look at how lightweight
message passing concurrency can be used to build very complex
and robust systems. Jocaml is a very interesting start.
Right now, the main language that I see as an interesting
contender for our type of products is Haskell, because it
combines very good performance with very good support for
lightweight concurrency /and/ offers very high productivity.
I'm surprised. [...]
Moreover, the paper describing Haskell's parallel GC gives
> performance figures showing some applications degrading
> in performance when moving from 4 to 8 cores. So I
> think the Haskell community's claim that it is "good for
parallelism" is a triumph of hope over reality.
I'm not into shared-memory parallelism. For me, it's much
more important that the language be good at coordination
between tasks - since failure in that area means death
by complexity in my domain.
There was a project comparing Erlang and C++ for telecoms
software, which also looked at Glasgow Distributed Haskell
for the same tasks. While it came to some fairly concrete
conclusions re. Erlang vs C++, the work on Haskell was not
exhaustive enough to be directly comparable. Still, I would
view the preliminary results as very interesting.
F# could also potentially be interesting (if the underlying
concurrency support would improve substantially in terms
of thread creation, number of threads, scheduling cost, etc.,
and I have reason to believe it will). The main obstacle
is that we are extremely wary of vendor lock-in, both in
terms of programming language and operating system.
And as for exploiting multicore, we simply cannot get
our hands on enough cores quickly enough (mainly because
we need them in compact NEBS-compliant embedded systems).
But we ship dual-core systems today, and got a 1.7x
speedup without even recompiling the code. Very soon,
we'll move to quad-cores, and expect corresponding
speedups again. 8-core boards are on the horizon.
Dell's eight core desktops are now only £1,080! :-)
Well, a single-core NEBS-compliant rack-mountable Dell
server with 128 MB RAM is over $5,000! (:
(Not that we could use those either. We need Micro TCA
form factor.)
BR,
Ulf W
_______________________________________________
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
