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 66EF1BB81 for ; Wed, 8 Mar 2006 23:11:02 +0100 (CET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28MB1Rn004931 for ; Wed, 8 Mar 2006 23:11:02 +0100 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1FH6rr-0006qW-00; Wed, 08 Mar 2006 23:10:51 +0100 Received: from [84.58.132.179] (helo=gate.lan.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1FH6rr-0000og-00; Wed, 08 Mar 2006 23:10:51 +0100 Received: from flakew.lan.gerd-stolpmann.de (flakew.lan.gerd-stolpmann.de [192.168.0.32]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id C5C62C018; Wed, 8 Mar 2006 23:10:50 +0100 (CET) Subject: Re: [Caml-list] STM support in OCaml From: Gerd Stolpmann To: skaller Cc: Brian Hurt , caml-list@yquem.inria.fr, William Lovas In-Reply-To: <1141855594.23909.63.camel@budgie.wigram> 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> Content-Type: text/plain Date: Wed, 08 Mar 2006 23:10:50 +0100 Message-Id: <1141855850.10771.100.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at concorde with ID 440F5675.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 donnerstag:01 posix:01 afaik:01 interprocess:01 posix:01 interprocess:01 mutexes:01 mutexes:01 implements:01 threads:01 behaves:01 gerd: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.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 Am Donnerstag, den 09.03.2006, 09:06 +1100 schrieb skaller: > On Wed, 2006-03-08 at 14:45 -0600, Brian Hurt wrote: > > > One comment I will make is that a mutex is expensive, but not *that* > > expensive. I just wrote a quick program (available if anyone cares) in > > GNU C that measures the cost, in clocks, of locking and unlocking a posix > > mutex. On my desktop box (AMD Athlon XP 2200+ 1.8GHz), I'm getting a cost > > of like 44 clock cycles. Which makes it less expensive than an L2 cache > > miss. > 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(). And Linux even implements threads as processes, so you can even place mutexes in shared memory (but do not ask me how). Anyway, measuring the costs of a mutex is probably not simple. They are highly optimized for the frequently occurring cases. And today "SMP" behaves often more like NUMA, especially for multi-core CPUs. > As mentioned before the only data I have at the moment > 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. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------