English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2009-02-17 (17:14)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Threads performance issue.

On 17-02-2009, Yaron Minsky <yminsky@gmail.com> wrote:
> Interestingly, this probably has nothing to do with the size of the buffer.
> input_char actually acquires and releases a lock for every single call,
> whether or not an underlying system call is required to fill the buffer.
> This has always struck me as an odd aspect of the in/out channel
> implementation, and means that IO is a lot more expensive in a threaded
> context than it should be.
> On Tue, Feb 17, 2009 at 5:07 AM, Sylvain Le Gall <sylvain@le-gall.net>wrote=
>> You are using input_char and standard IO channel. This is a good choice
>> for non-threaded program. But in your case, I will use Unix.read with a
>> big buffer (32KB to 4MB) and change your program to use it. As
>> benchmarked by John Harrop, you are spending most of your time in
>> caml_enter|leave_blocking section. I think it comes from reading using
>> std IO channel which use 4k buffer. Using a bigger buffer will allow
>> less call to this two functions (but you won't win time at the end, I
>> think you will just reduce the difference between non-threaded and
>> threaded code).

You are probably true concerning the fact that it has nothing to do with
size of the buffer. I am just mixing two kind of optimization. Anyway, I
think even if the size is not important, using Unix.read + file
descriptor should do the trick.

Thanks for your detailed explanation.

Sylvain Le Gall