From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id B57D6BBAF for ; Wed, 27 Oct 2010 17:30:24 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJLix0zVuiYS/2dsb2JhbAChWXG+Xg2FOwQ X-IronPort-AV: E=Sophos;i="4.58,246,1286143200"; d="scan'208";a="64436243" Received: from solaria.dimino.org ([213.186.38.18]) by mail3-smtp-sop.national.inria.fr with ESMTP; 27 Oct 2010 17:30:24 +0200 Received: from aurora (localhost.localdomain [127.0.0.1]) by solaria.dimino.org (Postfix) with ESMTP id E29A780048; Wed, 27 Oct 2010 17:30:23 +0200 (CEST) Received: by aurora (Postfix, from userid 1000) id EF25F414B5; Wed, 27 Oct 2010 17:30:26 +0200 (CEST) Date: Wed, 27 Oct 2010 17:30:26 +0200 From: =?iso-8859-1?Q?J=E9r=E9mie?= Dimino To: Goswin von Brederlow Cc: caml-list@inria.fr Subject: Re: [Caml-list] Asynchronous IO programming in OCaml Message-ID: <20101027153026.GD32282@aurora> References: <20101024225037.GA8999@aurora> <87y69mk6jm.fsf@frosties.localdomain> <20101025111022.GA32282@aurora> <20101025143317.GB32282@aurora> <20101025172633.GC32282@aurora> <877hh4dlog.fsf@frosties.localdomain> <20101027111835.GA5664@gaia> <877hh33g52.fsf@frosties.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877hh33g52.fsf@frosties.localdomain> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam: no; 0.00; ocaml:01 0200,:01 memcpy:01 commited:01 threads:01 threads:01 wrote:01 caml-list:01 writes:01 data:02 asynchronous:03 programming:03 benchmark:04 problem:05 parallel:05 On Wed, Oct 27, 2010 at 03:43:37PM +0200, Goswin von Brederlow wrote: > But then you tune your benchmark to give you the result you want instead > of benchmarking what normaly happens. That's true for read or write. The point i wanted to make is that in the general case, i.e. for a system call that blocks, wrapping it into a thread might not be a good solution because it degrades performances too much. > And don't forget. Multi core systems are more and more widely > spread. What is wrong with 2 cores doing memcpy twice as fast? I don't think you can read or write in parallel the RAM with current architectures, but i may be wrong. > Do you have a different solution for writes that will avoid threads when > a write won't block? And how do you restart jobs once the data has > actually been commited to disk? (i.e. how do you do fsync()?) Unfortunately no, we have no solution for write. The main problem i see with doing write in parallels with threads is to handle errors. Jérémie