From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 44257BC37 for ; Tue, 30 Jun 2009 03:35:20 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQCAGcISUpQW+UCe2dsb2JhbACZAAEBFiQEszWEDQWBNw X-IronPort-AV: E=Sophos;i="4.42,312,1243807200"; d="scan'208";a="32177217" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 30 Jun 2009 03:35:19 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MLSFf-0000P3-NY for caml-list@inria.fr; Tue, 30 Jun 2009 01:35:15 +0000 Received: from elehack.net ([216.243.177.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jun 2009 01:35:15 +0000 Received: from michael by elehack.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jun 2009 01:35:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Michael Ekstrand Subject: Re: OCaml runtime lock does not seem pathological Date: Mon, 29 Jun 2009 20:31:51 -0500 Message-ID: <87ocs6zeuw.fsf@jehiel.elehack.net> References: <874otz0xz2.fsf@jehiel.elehack.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: elehack.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (gnu/linux) Cancel-Lock: sha1:M3QAO/x/ybKTEHkxiuXVNqSOWBM= Sender: news X-Spam: no; 0.00; ocaml:01 runtime:01 ocaml:01 pred:01 allocating:01 iteration:01 runtime:01 avoided:01 python's:01 gpg:01 pathological:98 threads:01 rec:01 ints:01 int:01 X-Attachments: type="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Michael Ekstrand writes: > The basic test which demonstrated this problem was a simple loop > counting down from 100000000. On Python, if two such loops are run in > parallel using threads on a multicore machine, the program takes > substantially longer to finish if the loops are run sequentially. > Disabling one core speeds the program up, but it doesn't recover all of > its original speed. > > I duplicated this test with the following code: > > let rec count n =3D > if n <=3D 0 then () > else count (pred n) > ;; > > (* count 100000000;; *) > (* count 100000000;; *) > > let t1 =3D Thread.create count 100000000;; > let t2 =3D Thread.create count 100000000;; > Thread.join t1;; > Thread.join t2;; Philippe Wang kindly told me that this isn't accurately measuring the potential problem as it is not allocating any memory and thus not triggering thread switching. I have therefore modified it to use Int64's and also to allocate an array of 32 ints in each iteration of the loop. The resulting program runs at equivalent speed both sequentially and in parallel with both cores enabled (perhaps slightly slower in parallel, but not significantly at all). Running the parallelized version with one core disabled does result in a noticeable slowdown (runtime goes from 8.86s to 9.63s, but still not on the scale reported for Python. So it does seem that, unless I am still not doing sufficient tests to detect a problem, OCaml has avoided Python's problem. =2D Michael =2D-=20 mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see . --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpJawgACgkQJMBfXHjb5YWtMACfTubsBsr/SCeDecfprI89C/Ov ZKgAn2c1qYo3PQbTG21qgNW3edFX/Bru =5iJy -----END PGP SIGNATURE----- --=-=-=--