Re: [Caml-list] Re: Arithmetic operations

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8724 bytes --]

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 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 <philou@philou.ch> 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 à 14:19, Gabriel Scherer a écrit :
>
> 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 Leroy'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" and
> some more. I think there is no clear consensus right now on what that would
> be, and that's why it hasn't been done yet, but there are several orthogonal
> efforts 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 would have
>> 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 à 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-ocamlmeeting-in-paris-debian-summary
>
>
> 2011/3/31 Philippe Strauss <philou@philou.ch>
>
>> 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, using
> 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 Ocamlcore
> 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 that
> things that are now rare are taken for granted in the future. Nobody, except
> maybe Sylvain, has the devotion to work full-time on the small details 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 Batteries is
> tedious and certainly less sexy that a lot of things you're working on. But
> 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 <philou@philou.ch>
>>
>>>
>>> Le 31 mars 2011 à 10:19, Pierre-Alexandre Voye a écrit :
>>>
>>> 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 others,
>>> 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 have
>>> more users than a complete alternative.
>>>
>>> the way you can get haskell packaged easily, on the contrary, as some big
>>> 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 Leroy's
>> team of course.
>>
>>
>> --
>> ---------------------
>> Isaac Project - http://www.lisaac.org/
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 11830 bytes --]