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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id A9319BC57 for ; Tue, 30 Nov 2010 16:31:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4BAIOn9EzVSycNkWdsb2JhbACDUJ9CFQEBAQEJCwoHEQMfsm2RIoEhgzNzBIpigw8G X-IronPort-AV: E=Sophos;i="4.59,280,1288566000"; d="scan'208";a="90417902" Received: from cpsmtpb-ews08.kpnxchange.com ([213.75.39.13]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Nov 2010 16:31:33 +0100 Received: from cpbrm-ews05.kpnxchange.com ([10.94.84.136]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Nov 2010 16:31:33 +0100 Received: from CPSMTPM-CMT103.kpnxchange.com ([195.121.3.19]) by cpbrm-ews05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Nov 2010 16:31:32 +0100 Received: from [192.168.2.4] ([84.80.25.83]) by CPSMTPM-CMT103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 30 Nov 2010 16:31:32 +0100 Message-ID: <4CF518A6.9000602@planet.nl> Date: Tue, 30 Nov 2010 16:30:46 +0100 From: Stephan Houben User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 Newsgroups: fa.caml To: Gerd Stolpmann Cc: caml-list@yquem.inria.fr Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2010 15:31:32.0666 (UTC) FILETIME=[AA9CC1A0:01CB90A3] X-RcptDomain: yquem.inria.fr X-Spam: no; 0.00; threading:01 ocaml:01 gerd:01 stolpmann:01 model:01 semaphores:01 blog:98 blog:98 restructure:98 threads:01 wrote:01 defines:01 caml-list:01 functions:01 computation:01 On 11/30/2010 02:22 PM, Gerd Stolpmann wrote: > I don't think this is the reason. Many people can ignore Windows, > actually. > > The problem is more that your whole program needs then to be > restructured - multi-processing implies a process model (which is the > master, which are the workers). With multi-threading you can start > threads at all times without having to worry about that (i.e. supports > "programming without design" if you want to take that as a negative > point). > > This is what I want to fix with my Netmulticore library - it defines a > framework allowing you to start new processes at any time without having > to worry about the process hierarchy. I have in fact read with much interest your blog at http://blog.camlcity.org/blog/parallelmm.html . Your approach there is to really have separate programs for server and client. However, one nice thing about fork is that you don't have to restructure your program; you can just call fork down somewhere in some subroutine where you decide it is convenient, start doing some multicore computation, finish and return, and the caller needs never know that you did that. So you can indeed program without design using fork. Of course, the advantage of your approach is that you can now distribute the work over multiple machines. So I guess there is an appropriate place for all of these techniques. > Also, many practical problems are only O(n log n), at most. The cost for > serialization of data through a pipe cannot be neglected here. This > makes shared memory attractive, even if it is only available in a > restricted form (like write once memory). Well, the original context was one of a benchmark which had an arbitrary rule that you can only use functions from the bundled libraries. And my proposal was to use the pipe for synchronisation and the shared memory for bulk communication. If we drop the arbitrary rule there are faster options than pipes. (e.g. POSIX semaphores in a shared memory segment). Stephan