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.9 required=5.0 tests=AWL,HTML_MESSAGE 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 DE4EBBBC1 for ; Mon, 21 Apr 2008 15:29:36 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFAPIzDEjAXQIm/2dsb2JhbACCMzakHoMi X-IronPort-AV: E=Sophos;i="4.25,689,1199660400"; d="scan'208";a="25271007" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 21 Apr 2008 15:29:36 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m3LDTZeY008983 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 21 Apr 2008 15:29:36 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcCAAMzDEhKfS4ec2dsb2JhbACCMzaObgEMAwQFCRSUfIMi X-IronPort-AV: E=Sophos;i="4.25,689,1199660400"; d="scan'208";a="9841951" Received: from yw-out-2324.google.com ([74.125.46.30]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Apr 2008 15:29:35 +0200 Received: by yw-out-2324.google.com with SMTP id 3so836549ywj.27 for ; Mon, 21 Apr 2008 06:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=5kCYlK8Kr8mmZRuKf5fvBca16ZcfYUIGhu6iPxtmKF4=; b=gHF/sOcsPPyCbN1PdptTsKUeZAwjvYRinR8hpmZSa380f66Bcn/tRYo4waV1pUlpQhh+gBSjKtdbM/UmJs491hIs88li3UJZ0tg/n/Mehno2wkVs+4uHFE9IgIsLl7qJEVYwWd1GLtJhCs30vdyqvusioCW2eb64B3Wp9DGfKnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dHM9gxP4x4Yw6VsqmH/7+wCHpid4lKAFGT9yBPH89v4Fxz8ZVYVoedv+/TOqVP39qS6udmtB65v7VneE75O08XNiLeQJ3Dn4Way5p8fzZUkOSzqWQ3vp4tLcDOMVMKo8MKYExB1bUbFEGmnnXkNnMWucwnCMYUXu2ocOVy/V6zI= Received: by 10.142.70.13 with SMTP id s13mr1692818wfa.162.1208784572172; Mon, 21 Apr 2008 06:29:32 -0700 (PDT) Received: by 10.142.153.9 with HTTP; Mon, 21 Apr 2008 06:29:32 -0700 (PDT) Message-ID: Date: Mon, 21 Apr 2008 15:29:32 +0200 From: "Berke Durak" To: "Richard Jones" Subject: Re: [Caml-list] The closing gap (warning: long, inflammatory rant) Cc: "Caml List" In-Reply-To: <20080421131151.GA16777@annexia.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13422_20032174.1208784572178" References: <20080421131151.GA16777@annexia.org> X-Miltered: at discorde with ID 480C96C0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 niches:01 ocaml:01 monadic:01 compilation:01 model:01 ocaml:01 cmx:01 cmi:01 cmo:01 flags:01 ocamlfind:01 X-Attachments: cset="UTF-8" cset="UTF-8" ------=_Part_13422_20032174.1208784572178 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Apr 21, 2008 at 3:11 PM, Richard Jones wrote: > Your threaded code is going to look really stupid when you have NUMA > machines with dozens of cores. Why are we optimizing for a case (SMP) > which will only be around for a few years. Arguably SMP isn't even > around now ... the AMD machine on which I'm typing this is firmly NUMA > with a good 10% penalty for accessing memory owned by the other > socket. Yes, that's why some of us don't buy too much shares in semaphore factories. > A concurrent GC should be developed. But I think you can compete in > some "niches" without a concurrent GC. Why should a concurrent GC be developed? Threaded code is a nightmare > to write & debug, and it's only convenient for lazy programmers who > can't be bothered to think in advance about how they want to share > data. OCaml supports fork, event channels & shared memory right now > (and has done for years) so there is no penalty to writing it > properly. Why not? Let's be conciliant. If people want to develop a concurrent GC, let them have a try. BTW I'm not a thread guy - I don't like POSIX threads very much. I really appreciate Lwt and use my monadic threads when developing my own stuff. > Compilation and linking are extremely painful things, especially when you > > want to start to learn a new language > > in good faith. Java has a relatively good packaging/loading model which > is > > part of its success. Ocaml is > > terrible at this. > > Huh? OCaml scripts work perfectly well, they're compiled when you run > them. I use them all the time. Yes, while I don't use them, Ocamlscripts are certainly nice thing, thank you for that. Compiling an Ocaml program remains quite an involved task, with all those not very inspectable cma, cmx, cmi, cmo, dll.so and cmxas floating around (cmigrep helps a lot) with their C flags and DLL lists. It gets even more complicated when you need to use native code or preprocessors. Ocamlfind helps a bit, ocamlbuild a bit more, but it's still painful. In Java, if you don't use native code, you just make a jar and ship the classes: jar cf foo.jar foo/, upload, java -jar foo.jar. [...] > > So there is a gap to be filled, and Ocaml could be the next fashionable > web > > programming language if we fix > > a few things or two: > > - Compilation and package headache, > > - Missing batteries. > > What distro are you using? Obviously one where you can't just > apt-get / yum install / godi whatever all the libraries and support > software you need. There is no "package headache" over in Debian / > Fedora / GODI at all. I'm not talking of packages in general - I'm using Godi on Debian and Ubuntu, but I'm talking about packaging Ocaml libs during development time. We need an easy-to-use lightweight packaging mechanism for developers and that has been discussed many times on this list. Godi is more or less OK when you passively use libraries, but it's non-trivial to inject your own stuff (even if it's just for yourself). Let's not start ye olde package management thread again. The fact is that there is large room for improvement :) -- Berke ------=_Part_13422_20032174.1208784572178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Apr 21, 2008 at 3:11 PM, Richard Jones <rich@annexia.org> wrote:
Your threaded code is going to look really stupid when you have NUMA
machines with dozens of cores.  Why are we optimizing for a case (SMP)
which will only be around for a few years.  Arguably SMP isn't even
around now ... the AMD machine on which I'm typing this is firmly NUMA
with a good 10% penalty for accessing memory owned by the other
socket.

Yes, that's why some of us don't buy too much shares in semaphore factories.

> A concurrent GC should be developed.  But I think you can compete in
> some "niches" without a concurrent GC.

Why should a concurrent GC be developed?  Threaded code is a nightmare
to write & debug, and it's only convenient for lazy programmers who
can't be bothered to think in advance about how they want to share
data.  OCaml supports fork, event channels & shared memory right now
(and has done for years) so there is no penalty to writing it
properly.

Why not?  Let's be conciliant.  If people want to develop a concurrent GC,
let them have a try.  BTW I'm not a thread guy - I don't like POSIX threads
very much.  I really appreciate Lwt and use my monadic threads when developing
my own stuff.

> Compilation and linking are extremely painful things, especially when you
> want to start to learn a new language
> in good faith.  Java has a relatively good packaging/loading model which is
> part of its success.  Ocaml is
> terrible at this.

Huh?  OCaml scripts work perfectly well, they're compiled when you run
them.  I use them all the time.

Yes, while I don't use them, Ocamlscripts are certainly nice thing, thank you for that.
Compiling an Ocaml program remains quite an involved task, with all those not very
inspectable cma, cmx, cmi, cmo, dll.so and cmxas floating around (cmigrep helps a lot) with
their C flags and DLL lists.  It gets even more complicated when you need to use
native code or preprocessors.  Ocamlfind helps a bit, ocamlbuild a bit more, but
it's still painful.

In Java, if you don't use native code, you just make a jar and ship the classes: jar cf foo.jar foo/,
upload, java -jar foo.jar.

[...]
> So there is a gap to be filled, and Ocaml could be the next fashionable web
> programming language if we fix
> a few things or two:
> - Compilation and package headache,
> - Missing batteries.

What distro are you using?  Obviously one where you can't just
apt-get / yum install / godi whatever all the libraries and support
software you need.  There is no "package headache" over in Debian /
Fedora / GODI at all.

I'm not talking of packages in general - I'm using Godi on Debian and Ubuntu,
but I'm talking about packaging Ocaml libs during development time.
We need an easy-to-use lightweight packaging mechanism for developers and that has
been discussed many times on this list.  Godi is more or less OK when you passively
use libraries, but it's non-trivial to inject your own stuff (even if it's just for yourself).
Let's not start ye olde package management thread again. The fact is that there is
large room for improvement :)

--
Berke
------=_Part_13422_20032174.1208784572178--