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=2.3 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL 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 EC92ABBAF for ; Sat, 20 Dec 2008 20:33:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBAIbWTEnRVdwKk2dsb2JhbACTKD4BAQEBCQkKCREDqDhYhFeMBQEDAQOGQIJY X-IronPort-AV: E=Sophos;i="4.36,255,1228086000"; d="scan'208";a="20652237" Received: from mail-fx0-f10.google.com ([209.85.220.10]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 Dec 2008 20:33:02 +0100 Received: by fxm3 with SMTP id 3so246283fxm.3 for ; Sat, 20 Dec 2008 11:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=q/ezui3U554MzciW3qc/dkrsNZxRh68dSUKoG2xuirw=; b=P0rwelHPNwdCupNxWBjuBQNHwhSKz4ROgSzp2zxg/9l0reknc+0NyZeiPYCaYijBJ8 vtyQWWf8Uwlbi1FrUGS6bO+Pv3B1aq1VIuKKG/MUIyfk/QFldrvy2GvCzb0ZTts04XHZ UBPKlxEqMFpEtDw4adZwZhBPXO9RSCr0/hdgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=VzrcGuTi7d9D5KWNvHCGeUJLmNU9zM9t+7ngJEVSLb67usaFJn8br1HiCgocTnGEtU f+SuhMXuh7D5t3vAvfNSSg0ZEhOAcUS7fkOzB/T+cMShRqkaq+DMCi7ZJeL810SZreui 8JtRwnohg4g3Ont/hmnGQUbv8nIuBNpGzZMLk= Received: by 10.181.223.2 with SMTP id a2mr622543bkr.135.1229801581438; Sat, 20 Dec 2008 11:33:01 -0800 (PST) Received: by 10.181.203.8 with HTTP; Sat, 20 Dec 2008 11:33:01 -0800 (PST) Message-ID: Date: Sat, 20 Dec 2008 20:33:01 +0100 From: "=?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?=" Sender: mikkelfj@gmail.com To: "Jon Harrop" Subject: Re: [Caml-list] More cores Cc: caml-list@yquem.inria.fr In-Reply-To: <200812192231.33131.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <157727.93194.qm@web111508.mail.gq1.yahoo.com> <200812192231.33131.jon@ffconsultancy.com> X-Google-Sender-Auth: 0fe155e650e841a9 X-Spam: no; 0.00; mikkel:01 rgensen:01 mikkel:01 ocaml:01 ocaml:01 mutexes:01 model:01 oleg:01 compiler:01 mutexes:01 compiler:01 parallelism:01 non-trivial:01 node:01 model:01 2008/12/19 Jon Harrop : > ii) People used to choose OCaml because it was fast but lack of support for > multicores means that OCaml is no longer competitively performant for many > tasks on today's computers. That is definitely an argument. >> If your programming paradigm for concurrency is Threads+Mutexes, I think this model is necessary for systems programming, but I don't think we should look broader than this. I'm not really sure what separates threads from functions, but I'd like to be able to chain logic sequentially and concurrently in a way that sync primitives are available but usually not required, and in a way that efficiently handle concurrent operations in C libraries, including transaction operations. I believe Oleg did some work on this, but this work would likely benefit from compiler support. So the discussion should be a) is there any real interest in supporting multiple cores - when we look beyond concurrent GC and Mutexes? b) what are the basic primitives we need from the compiler to support a range of interesting concurrency models in an efficient manner. c) we are probably not inventing a new vector language - like fortress - super efficient at micro parallelism, but it should be possible to efficiently tap into the processing power available. d) error handling and asymmetric termination times of concurrent operations is non-trivial - you may not want to wait for all sub-tasks to complete before the main task does starts aggregating. And if you embed distributed concurrency you may want to reschedule a long running operation on a new node. This is not a compiler issue, but the compiler may support a failure model that makes this easier to handle in a generic way for a distributed library. Google often mentions the importance of abandoning failed tasks because a hard-drive is down ever so often, or something. The spawn multiple processes solutions we have today concerns me slightly because I'm not convinced that processes are cleaned up properly on failure. I may be wrong though. > I think ML has proven its worth and > it is time to begin developing a completely new open source ML > implementation. I think this sounds interesting. But before starting such an effort, it would be nice with more road map information from Inria. Do they want to include LLVM, or are there good reasons not to? More importantly, I believe Xavier is right about the non-scalability of plain threaded garbage collection. So I really think we need to understand how we want to obtain that parallelism efficiently. And when we understand that, perhaps Inria is more willing to listen to the multi-core argument? That said, it can't hurt to have an experimental solution to try out new ideas and prove that they work. Mikkel