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 2F6C5BBBC for ; Mon, 20 Mar 2006 17:15:58 +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 k2KGFvZj031299 for ; Mon, 20 Mar 2006 17:15:57 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA10681 for ; Mon, 20 Mar 2006 17:15:57 +0100 (MET) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k2KGFuHO031293 for ; Mon, 20 Mar 2006 17:15:56 +0100 Received: by xproxy.gmail.com with SMTP id t16so783029wxc for ; Mon, 20 Mar 2006 08:15:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RkGXDomsDcEPWiNbKn6bjsOrfJa4Ldju/YmZn6jlM8sS08/7aChnDOqi6myQftZwgyssOJA/r6ULf/+upVAx8MPwZ8b12ziN5mTDu7sqluyKzsPem+bf7Lpey7pxbzcVnI4d0DQSWXEpJ0gloMDnJjLB13kqO0Yy+6LyjKl4Z1E= Received: by 10.70.23.8 with SMTP id 8mr2290755wxw; Mon, 20 Mar 2006 08:15:54 -0800 (PST) Received: by 10.70.57.14 with HTTP; Mon, 20 Mar 2006 08:15:54 -0800 (PST) Message-ID: Date: Mon, 20 Mar 2006 11:15:54 -0500 From: "Markus Mottl" To: "Xavier Leroy" Subject: Re: [Caml-list] Severe loss of performance due to new signal handling Cc: ocaml In-Reply-To: <441E760D.6010801@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11404_23378886.1142871354138" References: <441E760D.6010801@inria.fr> X-Miltered: at nez-perce with ID 441ED53D.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 441ED53C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 cvs:01 bug:01 freezes:01 ocaml:01 cvs:01 bug:01 freezes:01 ocaml:01 dog:98 dog:98 W8:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=HTML_30_40,HTML_MESSAGE, INFO_TLD,RCVD_BY_IP autolearn=disabled version=3.0.3 ------=_Part_11404_23378886.1142871354138 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/20/06, Xavier Leroy wrote: > > Short explanation: atomic instructions are dog slow. Thanks for the explanation. I'd never have guessed that atomic instruction= s could be responsible for such a deterioration of performance. So, it's time to go back to the drawing board. Fortunately, it > appears that reliable polling of signals is possible without atomic > processor instructions. Expect a fix in 3.09.2 at the latest, and > probably within a couple of weeks in the CVS. > Great! Btw., since we are at it, you could also make us really happy by fixing issue 3906 in the next release, too. Now that the reason is clear this should be very straightforward, and would save people who write certai= n kinds of threaded code a lot of headaches, because this bug can cause all sorts of weird problems in long-running applications (freezes, crashes, execution of random code, etc.), and was extremely hard to trigger and trac= k down. Best regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com ------=_Part_11404_23378886.1142871354138 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/20/06, Xavier Leroy <Xavier.Leroy@inria.fr> wrote:
Short explanation: atomic instructions are dog slow.

Thanks for the explanation.  I'd never have guessed that atomic instructions could be responsible for such a deterioration of performance.

So, it'= s time to go back to the drawing board.  Fortunately, it
appea= rs that reliable polling of signals is possible without atomic
processor instructions.  Expect a fix in 3.09.2 at the latest= , and
probably within a couple of weeks in the CVS.

Great!  Btw., since we are at it, you could also make us really happy by fixing issue 3906 in the next release, too.  Now that the reason is clear this should be very straightforward, and would save people who write certain kinds of threaded code a lot of headaches, because this bug can cause all sorts of weird problems in long-running applications (freezes, crashes, execution of random code, etc.), and was extremely hard to trigger and track down.

Best regards,
Markus

--
Markus Mottl        http://www.ocaml.info      &n= bsp; markus.mottl@gmail.com<= /a> ------=_Part_11404_23378886.1142871354138--