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=0.7 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 7C4B9BC37 for ; Mon, 29 Jun 2009 19:10:17 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQCAEySSEpQW+UCe2dsb2JhbACYfgEBFiQEtTmEDQWBNw X-IronPort-AV: E=Sophos;i="4.42,310,1243807200"; d="scan'208";a="42626541" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 29 Jun 2009 19:10:17 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MLKMx-0005Pt-G0 for caml-list@inria.fr; Mon, 29 Jun 2009 17:10: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 ; Mon, 29 Jun 2009 17:10:15 +0000 Received: from michael+ocaml by elehack.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jun 2009 17:10:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Michael Ekstrand Subject: OCaml runtime lock does not seem pathological Date: Mon, 29 Jun 2009 12:08:17 -0500 Message-ID: <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:WTUhAJGN14Igv4L1m0BLEE/F8RQ= Sender: news X-Spam: no; 0.00; ocaml:01 ocaml:01 runtime:01 python's:01 ocaml's:01 runtime:01 python's:01 pred:01 byte:01 byte:01 ocaml's:01 gpg:01 pathological:98 buzz:98 0.28:98 X-Attachments: type="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Late last week, a presentation demonstrating substantial scaling problems with Python's global interpreter lock[1] got a bit of buzz. I was interested to see whether OCaml's runtime suffered from a similar problem, given that it too forbids multiple threads from concurrently accessing the runtime. The basic problem outlined is that Python's GIL implementation causes substantial lock contention, particularly on multicore machines, which causes computational threads to thrash against each other and can cause computational threads to keep I/O threads from running. This latter problem can result in an obscure priority inversion. 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;; Running sequentially on my 1.8 GHz Core 2 Duo laptop (Debian, AMD64) takes 3.38s user time in byte code and 0.28s user time in native code. Running threaded with both cores enabled takes the same time. Running threaded with the second core disabled also takes about the same time (byte code is slightly slower). The take-away from this is that while global locks can cause obscure performance problems, a very simplistic test suggests that OCaml's implementation avoids such problems and threaded solutions do scale (as well as any non-multicore-compatible solution can). I do not know how the locking for the OCaml runtime is done, so I do not know if there are deeper problems of this nature which more sophisticated testing would reveal. =2D Michael 1. http://blip.tv/file/2232410 =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) iEYEARECAAYFAkpI9QEACgkQJMBfXHjb5YW1kACdGjAJKDTfbWoLlb+Pt1LzDnPk WwAAn3Tp5EZYEw9+dTsSGSGwyK1oyhao =87X+ -----END PGP SIGNATURE----- --=-=-=--