From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 45335BB84 for ; Tue, 17 Feb 2009 18:14:20 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgCAK9+mklQW+UCe2dsb2JhbACUSQEBFiIEviSEEwY X-IronPort-AV: E=Sophos;i="4.38,224,1233529200"; d="scan'208";a="24221071" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 17 Feb 2009 18:14:20 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LZTWS-0004wZ-8d for caml-list@inria.fr; Tue, 17 Feb 2009 17:14:16 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Feb 2009 17:14:16 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Feb 2009 17:14:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Threads performance issue. Date: Tue, 17 Feb 2009 17:14:04 +0000 (UTC) Message-ID: References: <2184b2340902160715y1f935b5ehc0e6195b3f75b66b@mail.gmail.com> <891bd3390902160847p25ad3bf1pe59da620dfc667f2@mail.gmail.com> <2184b2340902160937i53b8f3fbga01eaf14ed829f8f@mail.gmail.com> <2184b2340902162340s540c5ac7g9f42b59d03f643cb@mail.gmail.com> <891bd3390902170420i6e7647ccl44c55456952d3f5a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/pre0.9.9-102 (Linux) Sender: news X-Spam: no; 0.00; le-gall:01 yaron:01 minsky:01 yminsky:01 buffer:01 buffer:01 le-gall:01 2009:98 threads:01 char:01 char:01 wrote:01 wrote:01 unix:01 unix:01 Hello, On 17-02-2009, Yaron Minsky 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 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. Regards Sylvain Le Gall