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.0 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 231CABB84 for ; Tue, 15 Jul 2008 17:21:15 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMCAABdfEhDWxLCbmdsb2JhbACBWpBeNpwe X-IronPort-AV: E=Sophos;i="4.30,367,1212357600"; d="scan'208";a="13134753" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jul 2008 17:21:14 +0200 Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16]) by server1.bertec.net (Postfix) with ESMTP id 195B91056D8 for ; Tue, 15 Jul 2008 11:21:13 -0400 (EDT) From: Kuba Ober To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: thousands of CPU cores Date: Tue, 15 Jul 2008 11:21:12 -0400 User-Agent: KMail/1.9.9 References: <1215721450.24773.25.camel@flake.lan.gerd-stolpmann.de> In-Reply-To: <1215721450.24773.25.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807151121.12401.ober.14@osu.edu> X-Spam: no; 0.00; gerd:01 stolpmann:01 donnerstag:01 gerd:01 stolpmann:01 ocaml:01 cygwin:01 afaik:01 cygwin:01 statically:01 trivial:01 cheers:01 wrote:01 wrote:01 unix:01 On Thursday 10 July 2008, Gerd Stolpmann wrote: > Am Donnerstag, den 10.07.2008, 20:07 +0000 schrieb Sylvain Le Gall: > > On 10-07-2008, Gerd Stolpmann wrote: > > > In Ocaml you can exploit multi-core currently only by using > > > multi-processing parallel programs that communicate over message > > > passing (and only on Unix). Actually, it's an excellent language for > > > this style. > > > > Why only on Unix ? > > No fork() on Windows. And emulating its effects is hard. > > I would subsume Cygwin under "pseudo-Unix", and its fork emulation is so > slow that it would be a problem for speedy programs. AFAIK, Cygwin's fork() emulation is quite limited since Cygwin didn't go the way of doing a custom process loader. I.e. instead of having a *tiny* statically linked loader executable which then actually brings in code and data pages into the process space (and would allow sharing them copy-on-write with other processes), they just use Windows for that, and that's why they have to emulate (and make up) their process IDs. Doing an exec() when you have your own loader is trivial: just tell the loader to deallocate all of the process's virtual memory (save for that of the loader's), and load something else instead. I have fiddled some time ago with a very basic custom loader which uses native API and it worked OK for what it did. Of course Cygwin has to work under win 95, so it has no access to native API there, but on anything modern it could easily have speeds comparable to native. I mean, Microsoft has implemented the Posix subsystem using same native API and its fork() works just fine (read: way better than Cygwin's). I have last delved into all this ~5+ years ago, so things may have changed in the meantime... Cheers, Kuba