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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D11BDBB81 for ; Thu, 9 Mar 2006 00:11:31 +0100 (CET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28NBTnr012239 for ; Thu, 9 Mar 2006 00:11:30 +0100 Received: from [192.168.1.200] (ppp9-113.lns1.syd7.internode.on.net [59.167.9.113]) by smtp3.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k28NBIDo092238; Thu, 9 Mar 2006 09:41:18 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] STM support in OCaml From: skaller To: Gerd Stolpmann Cc: Brian Hurt , caml-list@yquem.inria.fr, William Lovas In-Reply-To: <1141855850.10771.100.camel@localhost.localdomain> References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> <1141779125.20944.405.camel@budgie.wigram> <20060308193633.GA5460@coruscant.stwing.upenn.edu> <1141855594.23909.63.camel@budgie.wigram> <1141855850.10771.100.camel@localhost.localdomain> Content-Type: text/plain Organization: Async P/L Date: Thu, 09 Mar 2006 10:48:00 +1100 Message-Id: <1141861680.23909.116.camel@budgie.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 440F64A1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 donnerstag:01 afaik:01 interprocess:01 posix:01 interprocess:01 mutexes:01 mutexes:01 xavier's:01 posix:01 implements:01 threads:01 trivial:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Wed, 2006-03-08 at 23:10 +0100, Gerd Stolpmann wrote: > Am Donnerstag, den 09.03.2006, 09:06 +1100 schrieb skaller: > > I have no idea if Linux, for example, running SMP kernel, > > is smart enough to know if a mutex is shared between two > > processing units or not: AFAIK Linux doesn't support > > interprocess mutex. Windows does. Be interesting to > > compare. > > Of course POSIX supports interprocess mutexes: Mutexes are inherited > across fork(). How does that work with the address space being copied? On Windows, the mutex lives in kernel memory, the user only gets a handle to it. But at least with Xavier's pthread implementation (I assume this is Posix) you can do pthread_mutex_t fastmutex = PTHREAD_MUTEX_INITIALIZER; which indicates the mutex lives in user address space. Fork() copies the user address space (perhaps lazily). So it seems to me mutexes cannot work across fork()? > And Linux even implements threads as processes, so you > can even place mutexes in shared memory (but do not ask me how). I was thinking of Windows, where you can actually create inter-process global objects by naming them, and then find them in another unrelated process using the string name. [Placing a mutex is shared memory is the same as any other memory I guess: you just call pthread_mutex_init] > Anyway, measuring the costs of a mutex is probably not simple. Agreed! > > is a two thread counter increment experiment on a dual > > CPU G5 box, where the speed up from 2 CPUs vs 1 was > > a factor of 15 .. times SLOWER. > > You mean for a highly congested mutex you saw that slowdown. Yes, just one trivial experiment. Enough to suggest that merely upgrading from one core to two won't necessarily buy you a major performance increase. Probably better can be done with the right software, low level stuff using kernel calls, or even processor/board specific patches. AMD64 for example seems to have reasonably sophisticated ways of handling cache coherence which can't be provided generically by an OS like Linux that has to run on processors with different cache management architectures. Although these are low level issues, the really interesting ones are high level. Stuff like STM, control inversion, garbage collection, etc may be more portable and yield more benefits (especially if it is portable). But that is also hard to know without some significant applications and a lot of measurements. Anyhow I personally won't be writing off Ocaml any time soon! -- John Skaller Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net