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.9 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,RCVD_IN_NJABL_PROXY autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 92B5FBBAF for ; Thu, 24 Sep 2009 17:20:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwCAJcqu0pDww/NmGdsb2JhbACRSXqIPAEBAQEBCAkMBxOqYYExj3ABBQMBhBcF X-IronPort-AV: E=Sophos;i="4.44,446,1249250400"; d="scan'208";a="34920416" Received: from web111513.mail.gq1.yahoo.com ([67.195.15.205]) by mail3-smtp-sop.national.inria.fr with SMTP; 24 Sep 2009 17:20:23 +0200 Received: (qmail 83479 invoked by uid 60001); 24 Sep 2009 15:20:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253805622; bh=g/Ss9DW9X4Wc+eAEPtFdIKYk6nFpZqdMRcGPeIHqr/Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XamowVcihcjos38NCUjtS7x+L4fxu6tALrF59QvOUeOP6knlrzqZ3E1NBLSb7AYGLeFwQnSMvBiZ3/A2mf96Qyq+ZcYaGP1tQYyILo8EB3kXDM7cEeyjN9cz7MXmnbe9AzG69jx7mWyqD/hNxc0taL1LxXb6220412ROPZjPNss= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NcqhkpJQtpruum4NvoMT7mYRC0ABa5p3Hok9D/P1ZGsGLOkDI+vDlUwQxnDBIXz7/2rlenlFGYqUUR7sZk2UHFxYcuB6gfvdnM+kI0lOgXeEPMnLuexYDTEmNhgGd715TTcCf/WrZ5t+fwvx7qxzCG6f6VL11bpQ0bYNdnNpe/U=; Message-ID: <432748.82657.qm@web111513.mail.gq1.yahoo.com> X-YMail-OSG: urKXMYoVM1mHOche_acA5eUJq6_Ns_KPTHY2uOXpHLHBvIZSWePGhH6IvXsN8XsYdd4VLsOe5_jKcDs9Ob38fozDgTndPwl9vCYgCBp8T_Jn8OOBgF79PQB4w6UGCOwkabIbVaDoMgNEg6x9eACMEkdjeoHVqtbZ3PY49z4DzHPBlorMNScc93Bk2ZbjxqySK9HfGLidfbXiMHLcb4l4QZoWOQrHCbBreVw_NM0jWX8KAyL3yPhCajgmp4.RRU458GUFdReWIaga26QpwjnzlhFZI8AUj9UAueYIDw-- Received: from [213.205.70.208] by web111513.mail.gq1.yahoo.com via HTTP; Thu, 24 Sep 2009 08:20:22 PDT X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.3 Date: Thu, 24 Sep 2009 08:20:22 -0700 (PDT) From: Dario Teixeira Subject: Re: [Caml-list] OC4MC : OCaml for Multicore architectures To: Philippe Wang Cc: caml-list@inria.fr In-Reply-To: <4d1b2df20909240738g1ba80204ra8cd138ef5c58956@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocaml:01 ocaml's:01 ocaml:01 parallelism:01 parallelism:01 runtime:01 justifies:01 threads:01 threads:01 caml-list:01 variables:02 native:03 programming:03 library:03 concurrent:04 Hi,=0A=0A> Very few programs that are not written with multicore in mind wo= uld=0A> not be penalized. I mean our GC is much much dumber than INRIA OCam= l's=0A> one. Our goal was to show it was possible to have good performance = with=0A> multicores for OCaml. Maybe someday we'll find some time to optim= ize=0A> the GC, but it's likely not very soon.=0A=0AThanks for the clarific= ation. While not detracting from your work (which=0AI think is very intere= sting and valuable), for me single-thread performance=0Ais still paramount.= I am working in a domain (doing backend web application=0Aprogramming usi= ng the Ocsigen framework) where multi-threaded parallelism=0Ais a bit silly= , since you can get much better performance and design=0Asimplicity by runn= ing multiple independent servers (one for each core).=0AEach server runs mu= ltiple concurrent Lwt-threads (a cooperative form of=0Agreen threads) to ma= ke sure the CPU is always busy and not waiting on I/O.=0A=0AThis solution h= as the advantage of requiring no process context-switching=0Awithin each se= rver, while still maximising CPU utilisation. And I suspect=0Athere are ma= ny other fields where a similar approach could be used advantageously=0Ains= tead of thread-based parallelism.=0A=0A=0A> I guess that if INRIA decides t= o implement parallel threads capability,=0A> they will have to make the run= time library ready (clean up some global=0A> variables, tidy the code like = remove compatibility.h and such stuff)=0A> before thinking about the GC. Th= is could take some time, because it's=0A> not good to break everything at o= nce. Then, if they have finished this=0A> step, I would be confident that t= hey could integrate an awesome GC.=0A> But that's only my personal opinion.= ..=0A=0AAgain, it's a question of whether the cost justifies the benefits.= =0APersonally, I'm in the camp that would rather see improvements to=0Athe = type system (like native GADTS!)...=0A=0AAnyway, keep us appraised of your = work. It's very welcome.=0A=0ABest regards,=0ADario Teixeira=0A=0A=0A=0A =