From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2VDATuq013752 for ; Thu, 31 Mar 2011 15:10:29 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQCACF8lE3RVditkGdsb2JhbACeUwGGcAgUAQEBAQkJDQcUBCGIeRubFIpWgiOEai+IXAEBAwWFZgSNEYcEgg06 X-IronPort-AV: E=Sophos;i="4.63,275,1299452400"; d="scan'208";a="91606904" Received: from mail-qy0-f173.google.com ([209.85.216.173]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Mar 2011 15:10:23 +0200 Received: by qyk36 with SMTP id 36so4543369qyk.18 for ; Thu, 31 Mar 2011 06:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=W5MN6WBfvYs9MCbP494u3179WPzRFjrxk8mU9PZrLEA=; b=MdhWQ0Gd5CrDEGtUMyhoR2VON9RalxXelQZWmMQWSczrknfeQbTppRC6RHMyKw6zzR Vv8C5PQTbER43VtBf/2jKaGr5IjehqwTj6bIOAJhfBSE3b7ETinE8bwEufzJEnccZk3D VJmZy3klnZMqvZpV7n3k1dmN855wNwt/odIaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=R0ZvfKwByqP6Jd48C+RMNoOgLYqm5+7z97MW6Ok4JgeW2G1jiTuzzdPxX+qRKKmqGp /hS3sfAch7CXy5O576ULDnpdpcLArkft2CzdkBmaKjvlzCWRNXhe/LcqsLbeX+zUHF4G J4IimNyXxp8KYjB6oPZkoZvk+p9EN9RnGxaBo= Received: by 10.224.204.3 with SMTP id fk3mr2272129qab.177.1301577021317; Thu, 31 Mar 2011 06:10:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.146 with HTTP; Thu, 31 Mar 2011 06:10:01 -0700 (PDT) In-Reply-To: <133381EA-5DD1-4B00-A3BA-69127B259BE2@philou.ch> References: <4D9328A0.3020504@wp.pl> <25BB4625-7DB0-47E2-A378-5F121EB41EB8@gmail.com> <6FE49D01-1E57-4AB5-A9A7-5BEEFFDC59C9@philou.ch> <133381EA-5DD1-4B00-A3BA-69127B259BE2@philou.ch> From: Gabriel Scherer Date: Thu, 31 Mar 2011 15:10:01 +0200 Message-ID: To: Philippe Strauss , caml-list caml-list Content-Type: multipart/alternative; boundary=20cf300faf5d00e389049fc704d2 Subject: Re: [Caml-list] Re: Arithmetic operations --20cf300faf5d00e389049fc704d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2011 at 2:39 PM, Philippe Strauss wrote: > I became interested in O'Caml due to it's good numbers figures on the > language shootout perf. comparison back in 2001. It was regulary not far > behind C/C++. > Maybe it's a not big big effort to tackle the task of optimizing those > pesky benchmark to regains some rank and make the community grows again. > It was certainly an interesting time, but I don't think it's realistic to expect that "with some effort, we'll be number 2 on the shootout again". This specific "benchmark" has been discussed many times in the OCaml community and others (eg. Haskell), and it has been acknowledged, first and foremost by the shootout organizers, that you cannot deduce too much from it. What is measured is not "how fast typical programs of the language are" but "how fast is the massively tuned version conforming to the arbitrary rules (like all rules) of this benchmark" (eg. changing the GC settings are disallowed in benchmarks where that would make a huge difference, and simply changing the default pool sizes would have big differences on the accepted result, which is arguably a bit ridiculous). It may be obvious, but it turns out that massively tuned C program tends to be faster than massively tuned OCaml programs (because the OCaml compiler is quite straight wrt. optimization, so you can only tune so much), and that languages supporting more low-level techniques have an edge here. It is fair, I think, that new high-level language that were thought to accommodate well with low-level techniques, such as ATS, or languages with a fancier concurrency support, score better than OCaml on this benchmark. OCaml is on par with other well-designed and well-implemented functional languages such as Haskell or Common Lisp, and still roads ahead most dynamic languages such as Python or Ruby, or even Javascript (although LuaJIT is coming close to native speed). There is no reason why OCaml would or should perform significantly better in the near future. On Thu, Mar 31, 2011 at 2:39 PM, Philippe Strauss wrote: > just a thought, > > I became interested in O'Caml due to it's good numbers figures on the > language shootout perf. comparison back in 2001. It was regulary not far > behind C/C++. > Maybe it's a not big big effort to tackle the task of optimizing those > pesky benchmark to regains some rank and make the community grows again. > > I'm a bit too beginner for the task (mind polluted with imperatives :) > > dunnon, once again, just a thought. > > Le 31 mars 2011 =E0 14:19, Gabriel Scherer a =E9crit : > > 2011/3/31 Philippe Strauss > >> So, I think INRIA could continue to work on a good compiler, and company >> which make business whith ocaml could discuss between them to agreed on >> standards, via Ocamlcore for instance, with the agreement of Xavier Lero= y's >> team of course. >> > > Xavier Leroy has already said, for example during the former OCaml > Meetings, that they would be happy to link to a more complete "OCaml > distribution" provided by the community, including the core "INRIA lib" a= nd > some more. I think there is no clear consensus right now on what that wou= ld > be, and that's why it hasn't been done yet, but there are several orthogo= nal > efforts in that direction (more on that later). > > > 2011/3/31 Philippe Strauss > >> maybe batteries and janestreet core (to name nowadays alternatives) have >> too big ambitions: extension library aside INRIA's standard lib would ha= ve >> more users than a complete alternative. >> > [...] >> > I think it would be important and interesting to create a little >> organization which discuss bout a standard lib and would begin making a >> synthesis of all these "standard" library. >> > > Batteries is meant to be an extension of INRIA's stdlib, as a continuation > of the [Extlib] effort. Great care is taken that a code using the existing > standard library should be able to replace it with Batteries without > changing a line of code. If something breaks when converting to batteries, > it should be filed as a bug. > > [Extlib] http://code.google.com/p/ocaml-extlib/ > > The Core library from Jane Street has liberated itself from this > conservative position. Programs should be written directly using Core, and > it is not in principle easy to transition from INRIA's stdlib to Core (of > course you could include both and be careful to avoid conflicts with > "open"). The advantages are plenty: it allows Janestreet to provide a > coherent set of packages and make different design choices (arguably some > aspects of INRIA's stdlib are more "non choices"). On the other hand, it > means that direct "synthesis" of both efforts (Core and Batteries) is not > likely. There is also the difference that Batteries is a community-driven > effort, while Core is more internal to Jane Street; they would probably > welcome contributions, but their internal code is naturally their top > priority, and the external release model has been rather sporadic for now. > > > Le 31 mars 2011 =E0 10:19, Pierre-Alexandre Voye: > >> I think it would be important and interesting to create a little >> organization which discuss bout a standard lib and would begin making a >> synthesis of all these "standard" library. >> > > After the first OCaml Meeting, there has been some discussion on the Cocan > Wiki, but I think the site is down currently. > > http://le-gall.net/sylvain+violaine/blog/index.php?post/2008/01/30/36-oca= mlmeeting-in-paris-debian-summary > > > 2011/3/31 Philippe Strauss > >> the way you can get haskell packaged easily, on the contrary, as some big >> appeal. > > > Sylvain Le Gall has been working on a CPAN-like repository for OCaml, usi= ng > his "oasis" distribution tool: > http://oasis.forge.ocamlcore.org/oasis-db.html > > Sylvain has been doing great work for the OCaml community for some years. > With the help of other tools (ocamlfind, godi, ocamlbuild...), the Ocamlc= ore > Forge, etc., it is now more and more easy to use, share and deploy OCaml > code. Of course, there still are a lot of rough edges, but the only way to > go further is that the community (yes, you!) try to use those tools, > popularize them, and also report feedback on what could be improved. > > For a very long time, using OCaml has been a joyful but solitary activity. > If you want a more vibrant community, the only thing to do is to do your > part of the work as you would need the others to do. Set a standard, so t= hat > things that are now rare are taken for granted in the future. Nobody, exc= ept > maybe Sylvain, has the devotion to work full-time on the small details th= at > will improve things in the long run, and this is ok. Yes, writing an oasis > file (or even a META) or contributing an obvious function to Batteries is > tedious and certainly less sexy that a lot of things you're working on. B= ut > this won't happen magically. > > > > On Thu, Mar 31, 2011 at 11:38 AM, Pierre-Alexandre Voye < > ontologiae@gmail.com> wrote: > >> 2011/3/31 Philippe Strauss >> >>> >>> Le 31 mars 2011 =E0 10:19, Pierre-Alexandre Voye a =E9crit : >>> >>> It's funny, because I'm studying why language succeed or not, for my M1 >>> dissertation (M1 Management), and it's one of the big factor, among oth= ers, >>> of sucess. >>> Ocaml is highly expressive, so you could turn around, but it's a big >>> problem. >>> >>> I think it would be important and interesting to create a little >>> organization which discuss bout a standard lib and would begin making a >>> synthesis of all these "standard" library. >>> >>> >>> Personally I'm not that unhappy with the standard lib shipped by INRIA. >>> >>> maybe batteries and janestreet core (to name nowadays alternatives) have >>> too big ambitions: extension library aside INRIA's standard lib would h= ave >>> more users than a complete alternative. >>> >>> the way you can get haskell packaged easily, on the contrary, as some b= ig >>> appeal. >>> >>> >>> I think INRIA, and in particular the Xavier Leroy's team, make what they >> can. Their work isn't to maintain OCaml but mainly to do research. >> So, I think INRIA could continue to work on a good compiler, and company >> which make business whith ocaml could discuss between them to agreed on >> standards, via Ocamlcore for instance, with the agreement of Xavier Lero= y's >> team of course. >> >> >> -- >> --------------------- >> Isaac Project - http://www.lisaac.org/ >> > > > --20cf300faf5d00e389049fc704d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2011 at 2:39 PM, Philippe Strauss <philou@philou.ch> wrote:
=
I became interested in O'Caml due to it's good numbers figures on th= e=20 language shootout perf. comparison back in 2001. It was regulary not far behind C/C++.
Maybe it's a not big big effort to tackle the task of optimizing those pesky benchmark to regains some rank and make the=20 community grows again.

It was certainly an interesting time, but I don't think it's realis= tic=20 to expect that "with some effort, we'll be number 2 on the shootou= t=20 again". This specific "benchmark" has been discussed many ti= mes in the=20 OCaml community and others (eg. Haskell), and it has been acknowledged,=20 first and foremost by the shootout organizers, that you cannot deduce=20 too much from it. What is measured is not "how fast typical programs o= f=20 the language are" but "how fast is the massively tuned version=20 conforming to the arbitrary rules (like all rules) of this benchmark"= =20 (eg. changing the GC settings are disallowed in benchmarks where that=20 would make a huge difference, and simply changing the default pool sizes would have big differences on the accepted result, which is arguably a=20 bit ridiculous).

It may be obvious, but it turns out that massively tuned C program tends to be faster than massively tuned OCaml programs (because the OCaml=20 compiler is quite straight wrt. optimization, so you can only tune so=20 much), and that languages supporting more low-level techniques have an=20 edge here.

It is fair, I think, that new high-level language that were thought to=20 accommodate well with low-level techniques, such as ATS, or languages=20 with a fancier concurrency support, score better than OCaml on this=20 benchmark. OCaml is on par with other well-designed and=20 well-implemented functional languages such as Haskell or Common Lisp,=20 and still roads ahead most dynamic languages such as Python or Ruby, or=20 even Javascript (although LuaJIT is coming close to native speed). There is no reason why OCaml would or should perform significantly better in=20 the near future.



On Thu, Mar 31, 2011 at 2:39 PM, Philipp= e Strauss <philou@= philou.ch> wrote:
just a thought,

I be= came interested in O'Caml due to it's good numbers figures on the l= anguage shootout perf. comparison back in 2001. It was regulary not far beh= ind C/C++.
Maybe it's a not big big effort to tackle the task of optimizing t= hose pesky benchmark to regains some rank and make the community grows agai= n.

I'm a bit too beginner for the task (mind p= olluted with imperatives :)

dunnon, once again, just a thought.

=
Le 31 mars 2011 =E0 14:19, Gabriel Scherer a =E9crit :
=

2011/3/31 Philippe Strauss <philou@philou.ch>
So, I think INRIA could continue to work on a good compiler, and company which make business whith ocaml could discuss between them to agreed on standards, via Ocamlcore for instance, with the agreement of Xavier=20 Leroy's team of course.

Xavier Leroy has alrea= dy said, for example during the former OCaml Meetings, that they would be h= appy to link to a more complete "OCaml distribution" provided by = the community, including the core "INRIA lib" and some more. I th= ink there is no clear consensus right now on what that would be, and that&#= 39;s why it hasn't been done yet, but there are several orthogonal effo= rts in that direction (more on that later).


2011/3/31 Philippe Strauss <philou@philou.ch>
maybe batteries and janestreet core (to name nowadays alternatives) have too big ambitions: extension library aside INRIA's standard lib= =20 would have more users than a complete alternative.
[...]
I think it would b= e important and interesting to create a little organization which discuss bout a standard lib and=20 would begin making a synthesis of all these "standard" library.

Batteries is meant to be an extension of INRIA's stdlib, as a con= tinuation of the [Extlib] effort. Great care is taken that a code using the= existing standard library should be able to replace it with Batteries with= out changing a line of code. If something breaks when converting to batteri= es, it should be filed as a bug.

=A0[Extlib] http://code.google.com/p/ocaml-extlib/

The Core libr= ary from Jane Street has liberated itself from this conservative position. = Programs should be written directly using Core, and it is not in principle = easy to transition from INRIA's stdlib to Core (of course you could inc= lude both and be careful to avoid conflicts with "open"). The adv= antages are plenty: it allows Janestreet to provide a coherent set of packa= ges and make different design choices (arguably some aspects of INRIA's= stdlib are more "non choices"). On the other hand, it means that= direct "synthesis" of both efforts (Core and Batteries) is not l= ikely. There is also the difference that Batteries is a community-driven ef= fort, while Core is more internal to Jane Street; they would probably welco= me contributions, but their internal code is naturally their top priority, = and the external release model has been rather sporadic for now.


Le 31 mars 2011 =E0 10:19, Pierre-Alexandre Voye:
I think it would be import= ant and interesting to create a little organization which discuss bout a standard lib and=20 would begin making a synthesis of all these "standard" library.

After the first OCaml Meeting, there has been some = discussion on the Cocan Wiki, but I think the site is down currently.
=A0 http://le= -gall.net/sylvain+violaine/blog/index.php?post/2008/01/30/36-ocamlmeeting-i= n-paris-debian-summary


2011/3/31 Philippe Strauss <<= a href=3D"mailto:philou@philou.ch" target=3D"_blank">philou@philou.ch&g= t;
the way you can get haskell packaged easily, on the contrary, as some big a= ppeal.

Sylvain Le Gall has been working on a CPAN-like= repository for OCaml, using his "oasis" distribution tool:
=A0=A0 http://oasis.forge.ocamlcore.org/oasis-db.html
=
Sylvain has been doing great work for the OCaml community for some year= s. With the help of other tools (ocamlfind, godi, ocamlbuild...), the Ocaml= core Forge, etc., it is now more and more easy to use, share and deploy OCa= ml code. Of course, there still are a lot of rough edges, but the only way = to go further is that the community (yes, you!) try to use those tools, pop= ularize them, and also report feedback on what could be improved.

For a very long time, using OCaml has been a joyful but solitary activi= ty. If you want a more vibrant community, the only thing to do is to do you= r part of the work as you would need the others to do. Set a standard, so t= hat things that are now rare are taken for granted in the future. Nobody, e= xcept maybe Sylvain, has the devotion to work full-time on the small detail= s that will improve things in the long run, and this is ok. Yes, writing an= oasis file (or even a META) or contributing an obvious function to Batteri= es is tedious and certainly less sexy that a lot of things you're worki= ng on. But this won't happen magically.



On Thu, Mar 31, 2011 at 11:38 AM, Pierre-Alexandre Voye <on= tologiae@gmail.com> wrote:
2011/3/31 Philippe Strauss <philou@philou.c= h>

Le 31 mars 2011 =E0 10:19= , Pierre-Alexandre Voye a =E9crit :

It's funny, because I'm studying why language succeed or not, for = my M1 dissertation (M1 Management), and it's one of the big factor, amo= ng others, of sucess.
Ocaml is highly expressive, so you could turn around, but it's a big pr= oblem.

I think it would be important and interesting to create a little organi= zation which discuss bout a standard lib and would begin making a synthesis= of all these "standard" library.

Personally I'm not that unhappy with the standard lib shippe= d by INRIA.

maybe batteries and janestreet core (t= o name nowadays alternatives) have too big ambitions: extension library asi= de INRIA's standard lib would have more users than a complete alternati= ve.

the way you can get haskell packaged easily, on the con= trary, as some big appeal.


I think INRIA, and in particular the Xavier Leroy's team, m= ake what they can. Their work isn't to maintain OCaml but mainly to do = research.
So, I think INRIA could continue to work on a good compiler, and company wh= ich make business whith ocaml could discuss between them to agreed on stand= ards, via Ocamlcore for instance, with the agreement of Xavier Leroy's = team of course.


--
---------------------
I= saac Project - http://= www.lisaac.org/



--20cf300faf5d00e389049fc704d2--