Version française
Home     About     Download     Resources     Contact us    
Browse thread
Threads performance issue.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Threads performance issue.
Hello,

On 16-02-2009, Rémi Dewitte <remi@gide.net> wrote:
> --===============0282778124==
> Content-Type: multipart/alternative; boundary=00504502b0791d7c5b04630aa761
>
> --00504502b0791d7c5b04630aa761
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> Hello,
>
> I would like to read two files in two different threads.
>
> I have made a first version reading the first then the second and it takes
> 2.8s (native).
>
> I decided to make a threaded version and before any use of thread I realize=
> d
> that just linking no even using it to the threads library makes my first
> version of the program to run in 12s !
>

There is a small function call to handle thread
(caml_(enter|leave)_blocking_section). I don't know how much it cost in
term of performance but I am under the impression that it cost more time
than you win. These function calls can be found in many files all around
the OCaml source distribution... 

> I use pcre, extlib, csv libraries as well.
>

Some of this library can have a high cost for thread synchronisation on global
variable. You need to investigate. 

> I guess it might come from GC slowing down thinks here, doesn't it ? Where
> can it come from otherwise ? Is there a workaround or something I should
> know ?

Maybe... You need to look at external library and to benchmark your own
code... This is not an easy task.

>
> Can ocaml use multiple cores ?
>

As advertised in the OCaml documentation:

http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html

The threads library is implemented by time-sharing on a single
processor. It will not take advantage of multi-processor machines. Using
this library will therefore never make programs run faster. However,
many programs are easier to write when structured as several
communicating processes.

One of the point is that the GC doesn't take advantage of multiple-core.
Current GC that support this feature are slower than OCaml
single-threaded GC...

> Do you have few pointers on libraries to make parallel I/Os ?
>

Since you are running a fairly recent Linux kernel, I recommend you:
https://forge.ocamlcore.org/projects/libaio-ocaml/

which should allow you to use AIO (asynchronous IO in the kernel, see
"man aio_read").

Now on a more "ask-yourself" tone:

I have tried using thread to speed up IO on multiple core (in C code).
It is really tricky to get something that really work faster. In fact,
for reading you don't get performance at all when using threaded IO. I
am still asking myself why. I think it as something todo with the fact
that when you generate too much read request, the OS begin to do
inefficient I/O seek all around (almost no effect on Linux, timex4 on
Windows). As a matter of fact (for now), using non-threaded Unix.read
with 16k buffer and threaded Unix.write with 4M buffer is the most
efficient I/O scheme.

All in all, I think you should not try to use thread to improve your
software performance in OCaml - or rely on low-level asynchronous IO
(aio). 

Regards,
Sylvain Le Gall