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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 9DAFBBB81 for ; Tue, 21 Mar 2006 13:54:40 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k2LCseTb008449 for ; Tue, 21 Mar 2006 13:54:40 +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 NAA27973 for ; Tue, 21 Mar 2006 13:54:39 +0100 (MET) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by concorde.inria.fr (8.13.0/8.13.0) with SMTP id k2LCscxL005312 for ; Tue, 21 Mar 2006 13:54:39 +0100 Received: (qmail 21450 invoked from network); 21 Mar 2006 12:54:37 -0000 Received: from unknown (HELO ?192.168.1.100?) (rftp@pacbell.net@69.230.226.66 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Mar 2006 12:54:37 -0000 Message-ID: <441FF78D.8020309@rftp.com> Date: Tue, 21 Mar 2006 04:54:37 -0800 From: Robert Roessler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060318 SeaMonkey/1.5a MIME-Version: 1.0 To: Caml-list Subject: Re: [Caml-list] Severe loss of performance due to new signal handling References: <441E760D.6010801@inria.fr> <441F57FD.90206@rftp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 441FF790.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 441FF78E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; markus:01 mottl:01 assertion:01 os-dependent:01 byterun:01 markus:01 cached:01 toolchain:01 xavier's:01 compilation:01 nail:98 wrote:01 caml-list:01 msvc:01 macros: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 Markus Mottl wrote: > On 3/20/06, *Robert Roessler* > At the risk of being "irrelevant", I wanted to nail down exactly what > assertion is being made here: are we talking about directly executing > in assembly code the relevant x86[-64]/ppc/whatever instructions for > "read-and-clear", or going through OS-dependent access routines like > Windows' InterlockedExchange()? > > > We are talking of the assembly code. See file > byterun/signals_machdep.h, which contains the corresponding macros. Thanks, Markus - in the case you cite (direct instruction use), I was hoping for some illumination on this huge cost... reviewing the Intel manuals, I note that: 1) there is *no* claim that cache lines are flushed just by doing the xchg 2) in fact, with the Pentium Pro on, the bus LOCK# operation will not even happen if the data is cached - everything is left to the cache coherency mechanism 3) there *is* mention of processor *cache locking*, but this is still just in the context of cache coherency with multiple processors... so nothing here is suggesting cache line flushing or anything else that sounds horrendously expensive, particularly in the single CPU case < 8 hours later, back to finish email :) > Finally, it is interesting that you bring up this file - it appears as if the msvc toolchain is no longer supported for doing "correct" (in terms of Xavier's "atomicity w.r.t. signals") builds... at least that is how I interpret the conditional compilation directives. Robert Roessler roessler@rftp.com http://www.rftp.com