OCaml is broken

OCaml is broken

[Erik Rigtorp]

Hi!

I've been using Erlang and C++ to build a soft real-time system. As
the project has evolved we've needed to write more and more of the
code in C++ in order to achieve our latency requirements. But C++ is
not as performant as you might think until you start to write your own
allocators and cache aligning mallocs and datastructures. I've never
liked C++ so I decided to try OCaml and built a simple 100 line
program to build order books for Nasdaq. Turns out OCaml has really
competitive performance while being a really nice language.

However OCaml is broken! It does not provide any support for multicore
architectures, which by now is considered a bug! It doesn't even allow
me to load multiple runtimes into one C program.

Please fix OCaml! The first step would be to support multiple runtimes
running in the same process communicating using message queues.

Erik Rigtop

Re: [Caml-list] OCaml is broken

[Stéphane Glondu]

Erik Rigtorp a écrit :
> However OCaml is broken! It does not provide any support for multicore
> architectures, which by now is considered a bug! [...]

You might be interested by OCaml4Multicore:

  http://www.algo-prog.info/ocmc/web/

It's still experimental, but its authors would love to have feedback.


Best regards,

-- 
Stéphane

Re: OCaml is broken

[Sylvain Le Gall]

On 19-12-2009, Erik Rigtorp <erik@rigtorp.com> wrote:
>
> Please fix OCaml! The first step would be to support multiple runtimes
> running in the same process communicating using message queues.
>

You should take a look at:
http://jocaml.inria.fr/

Regards,
Sylvain Le Gall

Re: [Caml-list] OCaml is broken

[Thomas Fischbacher]

Erik Rigtorp wrote:

> However OCaml is broken! It does not provide any support for multicore
> architectures, which by now is considered a bug! It doesn't even allow
> me to load multiple runtimes into one C program.

My washing machine is broken. I cannot bake Pizza with it.

-- 
best regards,
Thomas Fischbacher
t.fischbacher@soton.ac.uk

Re: [Caml-list] OCaml is broken

[Gerd Stolpmann]

Am Samstag, den 19.12.2009, 10:30 +0100 schrieb Erik Rigtorp:
> Hi!
> 
> I've been using Erlang and C++ to build a soft real-time system. As
> the project has evolved we've needed to write more and more of the
> code in C++ in order to achieve our latency requirements. But C++ is
> not as performant as you might think until you start to write your own
> allocators and cache aligning mallocs and datastructures. I've never
> liked C++ so I decided to try OCaml and built a simple 100 line
> program to build order books for Nasdaq. Turns out OCaml has really
> competitive performance while being a really nice language.
> 
> However OCaml is broken! It does not provide any support for multicore
> architectures, which by now is considered a bug! It doesn't even allow
> me to load multiple runtimes into one C program.
> 
> Please fix OCaml! The first step would be to support multiple runtimes
> running in the same process communicating using message queues.

As you mention order books and soft-realtime, I guess your main concern
are minimized latencies. Well, you need then a style of parallelism that
focuses on a certain processing path for a single data item, and where
the latency is minimized by using several cores. I think ocaml is
unsuited for this type of task, but please don't call ocaml "broken"
because of this. Other types of parallelism can be well supported,
especially when you can accept multi-processing, and when you focus on
larger processing paths and partitioned data sets.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] OCaml is broken

[Erik Rigtorp]

On Sun, Dec 20, 2009 at 17:18, Gerd Stolpmann <gerd@gerd-stolpmann.de> wrote:
> As you mention order books and soft-realtime, I guess your main concern
> are minimized latencies. Well, you need then a style of parallelism that
> focuses on a certain processing path for a single data item, and where
> the latency is minimized by using several cores. I think ocaml is
> unsuited for this type of task, but please don't call ocaml "broken"

It is actually perfectly suitable for this, as long as you can run
multiple runtimes and share data via low latency message passing. This
is kind of how Erlang does it, with a separate heap for each
lightweight thread (called process in Erlang).

> because of this. Other types of parallelism can be well supported,
> especially when you can accept multi-processing, and when you focus on
> larger processing paths and partitioned data sets.

I agree, but fork() and pipe() has problems.

1. Latency is high ~10µs when tuned on Solaris, substantially higher
>100µs on Linux.
2. Runtimes don't share memory so data has to be copied. This is fine
for small datasets or streaming data, like passing order book updates
around.

Even if I want to process a dataset and partition it and sends the
work to multiple processes there is no framework in OCaml for me to
use.

Erik

Re: OCaml is broken

[Sylvain Le Gall]

On 21-12-2009, Erik Rigtorp <erik@rigtorp.com> wrote:
> On Sun, Dec 20, 2009 at 17:18, Gerd Stolpmann <gerd@gerd-stolpmann.de> wrote:
>
> Even if I want to process a dataset and partition it and sends the
> work to multiple processes there is no framework in OCaml for me to
> use.
>

There are many frameworks at hand, just search for it:
- ocamlp3l
- jocaml
- RPC with ocamlnet
- cothreads
- Ancient
- OCamlMPI

They maybe not look like exactly what you want, but they are close
enough to do what you want.

FYI, I have created a commercial application for sorting/processing big
files using OCaml. It runs using multi-processes as fast as other
commercial programs that do the same thing. In particular, it runs
faster than another well-known program written in C, using threads on
Windows and on Linux. 

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: OCaml is broken

[Richard Jones]

On Mon, Dec 21, 2009 at 09:21:09PM +0000, Sylvain Le Gall wrote:
> On 21-12-2009, Erik Rigtorp <erik@rigtorp.com> wrote:
> > On Sun, Dec 20, 2009 at 17:18, Gerd Stolpmann <gerd@gerd-stolpmann.de> wrote:
> >
> > Even if I want to process a dataset and partition it and sends the
> > work to multiple processes there is no framework in OCaml for me to
> > use.
> >
> 
> There are many frameworks at hand, just search for it:
> - ocamlp3l
> - jocaml
> - RPC with ocamlnet
> - cothreads
> - Ancient
> - OCamlMPI

Since the OP is interested in latencies, he may also want to look at
the tools lower down the stack for pinning processes and interrupts to
physical CPUs (eg. Tuna http://userweb.kernel.org/~acme/tuna/), and
also at RT kernels.

Red Hat is funding a large amount of research in this area under the
general brand name of MRG (Messaging, Real time and Grid computing):

http://www.redhat.com/mrg/

and we're doing this in partnership with some very large banks.

None of that is really specific to OCaml.  In fact the banks tend to
use Java(!)

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] OCaml is broken

[Florian Weimer]

* Erik Rigtorp:

> However OCaml is broken! It does not provide any support for multicore
> architectures, which by now is considered a bug!

The run-time library is sufficiently small so that you can run
multiple processes in parallel.  They will even share the code and
constant data.

> It doesn't even allow me to load multiple runtimes into one C
> program.

That should perhaps be fixed, yes.

Re: OCaml is broken

[Jeff Shaw]

My understanding is that since jocaml uses the regular ocaml runtime, it 
is also not multicore enabled.

Haskell is a functional language that has good performance that can use 
multiple processors, but the learning curve is steeper and higher.

OCaml is a close relative of Standard ML, so there might be some 
implementation of SML that you like. MLTon might allow multicore use, 
but I'm not sure how mature it is. SML/NJ has a library or language 
extension called Concurrent ML, but I think SML/NJ might not use 
multiple processors.

Note that if you're not using a lot of threads, you can use Unix.fork to 
do true multithreaded programming ocaml.

Re: [Caml-list] Re: OCaml is broken

[Jon Harrop]

On Saturday 19 December 2009 19:38:41 Jeff Shaw wrote:
> My understanding is that since jocaml uses the regular ocaml runtime, it
> is also not multicore enabled.
>
> Haskell is a functional language that has good performance

GHC and the Haskell language itself have serious performance problems.

> that can use multiple processors, but the learning curve is steeper and
> higher. 

And Haskell lacks many of the features OCaml programmers take for granted.

> OCaml is a close relative of Standard ML, so there might be some
> implementation of SML that you like. MLTon might allow multicore use,
> but I'm not sure how mature it is. SML/NJ has a library or language
> extension called Concurrent ML, but I think SML/NJ might not use
> multiple processors.

MLton and SML/NJ are both multicore incapable. The PolyML implementation of 
SML is multicore friendly but last time I looked (many years ago) it was 100x 
slower than OCaml for floating point.

As long as you're looking at OCaml's close relatives with multicore support, 
F# is your only viable option. Soon, HLVM will provide a cross-platform open 
source solution. If you look further you will also find Scala and Clojure.

> Note that if you're not using a lot of threads, you can use Unix.fork to 
> do true multithreaded programming ocaml.

We've discussed the problems with that before. Writing a parallel generic 
quicksort seems to be a good test of a decent multicore capable language 
implementation. Currently, F# is a *long* way ahead of everything open 
source.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [***SPAM*** Score/Req: 10.1/8.0] Re: [Caml-list] Re: OCaml is broken

[Erik Rigtorp]

On Sun, Dec 20, 2009 at 05:43, Jon Harrop <jon@ffconsultancy.com> wrote:
> As long as you're looking at OCaml's close relatives with multicore support,
> F# is your only viable option. Soon, HLVM will provide a cross-platform open
> source solution. If you look further you will also find Scala and Clojure.

F# is not viable since i'm developing for Solaris. I also believe the
.NET GC is not good enough for real-time systems. Clojure running
under real-time Java might be interesting.

It's too bad that INRIA is not interested in fixing this bug. No
matter what people say I consider this a bug. Two cores is standard by
now, I'm used to 8, next year 32 and so on. OCaml will only become
more and more irrelevant. I hate to see that happening.

I think right now only Erlang got this right and they have a great
library for developing enterprise applications too!

The first step for OCaml would be to be able to run multiple
communicating instances of the runtime bound to one core each in one
process and have them communicate via lock free queues.

Erik Rigtorp

Re: [***SPAM*** Score/Req: 10.1/8.0] Re: [Caml-list] Re: OCaml is broken

[Jon Harrop]

On Sunday 20 December 2009 12:21:44 Erik Rigtorp wrote:
> On Sun, Dec 20, 2009 at 05:43, Jon Harrop <jon@ffconsultancy.com> wrote:
> > As long as you're looking at OCaml's close relatives with multicore
> > support, F# is your only viable option. Soon, HLVM will provide a
> > cross-platform open source solution. If you look further you will also
> > find Scala and Clojure.
>
> F# is not viable since i'm developing for Solaris.

Yes. F# is Windows only for all intents and purposes.

> I also believe the .NET GC is not good enough for real-time systems.

Although heavily allocating threads will experience pauses of up to several 
seconds on .NET. However, threads that do not exceed their allocation quota 
run almost completely concurrently with the GC, so their real-time 
performance characteristics are good. This is the key to keeping UI threads 
responsive.

Note that OCaml's GC has some problems. Specifically, the stack and arrays of 
pointers in the heap are not traversed incrementally, incurring 
arbitrarily-long stalls.

> Clojure running under real-time Java might be interesting.

Sounds like you have hard RT guarantees.

> It's too bad that INRIA is not interested in fixing this bug.

They spent something like a decade trying to write a decent concurrent GC and 
pioneered the field.

> No matter what people say I consider this a bug.

A perf bug at best: it just means that OCaml is slower for many tasks.

> Two cores is standard by 
> now, I'm used to 8, next year 32 and so on. OCaml will only become
> more and more irrelevant. I hate to see that happening.

Me too. The OCaml language will continue to kick ass for some time to come but 
INRIA's implementation is no longer competitively performant for many tasks. 
However, open source offerings are all quite dire, particularly stand-alone 
ones.

> I think right now only Erlang got this right and they have a great
> library for developing enterprise applications too!

I couldn't disagree more. The *only* reason to work on parallelism is 
performance and Erlang's performance sucks. I know Erlang scales better, but 
it scales from poor absolute performance on 1 core to poor absolute 
performance on n cores. Hence Erlang is hardly the defacto standard for HPC 
on shared-memory supercomputers.

> The first step for OCaml would be to be able to run multiple
> communicating instances of the runtime bound to one core each in one
> process and have them communicate via lock free queues.

I think the first step is simply to replace OCaml's GC with a stop-the-world 
parallel one like the one I wrote for HLVM. The problem is that OCaml's data 
representation gives absolutely dire performance and kills scalability if you 
do that. So you either need to optimize the GC for this or rewrite everything 
from the ground up. OC4MC is doing the former. My HLVM project is doing the 
latter. Suffice to say, there is no easy solution (although I prefer 
mine ;-).

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: OCaml is broken

[Mihamina Rakotomandimby]

> Jon Harrop <jon@ffconsultancy.com> :
> > Two cores is standard by 
> > now, I'm used to 8, next year 32 and so on. OCaml will only become
> > more and more irrelevant. I hate to see that happening.  
> 
> Me too. The OCaml language will continue to kick ass for some time to
> come but INRIA's implementation is no longer competitively performant
> for many tasks. However, open source offerings are all quite dire,
> particularly stand-alone ones.

That seems dark...

-- 
       Architecte Informatique chez Blueline/Gulfsat:
    Administration Systeme, Recherche & Developpement
                +261 34 29 155 34 / +261 33 11 207 36