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 E0A7FBB81 for ; Thu, 9 Mar 2006 00:45:56 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k28NjuQA017028 for ; Thu, 9 Mar 2006 00:45:56 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA08786 for ; Thu, 9 Mar 2006 00:45:55 +0100 (MET) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by concorde.inria.fr (8.13.0/8.13.0) with SMTP id k28Njs10017025 for ; Thu, 9 Mar 2006 00:45:55 +0100 Received: (qmail 43572 invoked from network); 8 Mar 2006 23:45:46 -0000 Received: from unknown (HELO ?192.168.1.100?) (rftp@pacbell.net@69.230.226.66 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 8 Mar 2006 23:45:46 -0000 Message-ID: <440F6CB6.6030300@rftp.com> Date: Wed, 08 Mar 2006 15:45:58 -0800 From: Robert Roessler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060304 SeaMonkey/1.5a MIME-Version: 1.0 To: Caml-list Subject: Re: [Caml-list] STM support in OCaml 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 440F6CB4.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 440F6CB2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 rdtsc:01 afaik:01 interprocess:01 threads:01 doable:01 tougher:01 roof:98 wrote:01 wrote:01 caml-list:01 inline:01 kernel:01 kernel:01 caches: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 Brian Hurt wrote: > On Thu, 9 Mar 2006, skaller wrote: > >> Ahem. Now try that on an AMDx2 (dual core). The cost goes through >> the roof if one process has a thread on each core. Because each >> core has its own cache and both caches have to be flushed/ >> synchronised. And those caches are BIG! > > Love to. Wanna buy me the box? :-} Seriously- my code is attached, if > someone wants to run it on other boxes and post the results, feel free. > It's GNU-C/x86 specific, as I'm using GNU C's inline assembler and the > rdtsc instruction to get accurate cycle counts. > > As to the cache comment: the whole caches don't have to be flushed, just > the line the mutex is on. Which makes it approximately the cost of a > cache miss- that's a good approximation of the cost of getting an > uncontended lock. > >> >> 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. > > It doesn't look like the mutex software is even going into the kernel. I > don't think the Linux kernel even knows the mutex *exists*, let alone > what threads are competing for it. On the x86, at least, lock > instructions are not priveledged. Brian [, this may be fairly off-topic, but], could you possibly comment on how these results may or may not pertain to g_mutex_lock (rather than pthread_mutex_lock)? I have been going to some trouble to operate a glyph-string cache without needing any locking for the *lookup* case - which is doable, only needing locking for *adding*. OTOH, for the flushing operation, it looks a bit tougher... ;) But if g_mutex_lock/g_mutex_unlock is not all that grim... Robert Roessler roessler@rftp.com http://www.rftp.com