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 2AF67BBAF for ; Wed, 24 Nov 2010 07:55:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsJAM9F7EzCpx5ei2dsb2JhbACUP4YoAYgMFgELCyIivHuFTASNboJv X-IronPort-AV: E=Sophos;i="4.59,246,1288566000"; d="scan'208,217";a="89224987" Received: from sucre.univ-orleans.fr ([194.167.30.94]) by mail1-smtp-roc.national.inria.fr with ESMTP; 24 Nov 2010 07:55:49 +0100 Received: from localhost (localhost [127.0.0.1]) by sucre.univ-orleans.fr (Postfix) with ESMTP id 8087794385; Wed, 24 Nov 2010 07:55:49 +0100 (CET) Received: from sucre.univ-orleans.fr ([127.0.0.1]) by localhost (sucre.univ-orleans.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MmWxvYv2D+E; Wed, 24 Nov 2010 07:55:49 +0100 (CET) Received: from smtps.univ-orleans.fr (smtps.univ-orleans.fr [194.167.30.152]) by sucre.univ-orleans.fr (Postfix) with ESMTP id 6557C9435A; Wed, 24 Nov 2010 07:55:49 +0100 (CET) Received: from [192.168.0.10] (dau94-10-88-189-211-192.fbx.proxad.net [88.189.211.192]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 8BC8736E60; Wed, 24 Nov 2010 07:55:49 +0100 (CET) Subject: Re: [Caml-list] Re: Is OCaml fast? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-1-889419888 From: David Rajchenbach-Teller In-Reply-To: Date: Wed, 24 Nov 2010 07:55:48 +0100 Cc: Isaac Gouy , caml-list@inria.fr Message-Id: <0704C450-C5AD-4D02-8C7B-9659E4B918B5@univ-orleans.fr> References: <1290434674.16005.354.camel@thinkpad> <20101122180203.2126497sau3zukgb@webmail.in-berlin.de> <20101123232742.GC28768@siouxsie> To: Eray Ozkural X-Mailer: Apple Mail (2.1082) X-Spam: no; 0.00; ocaml:01 univ-orleans:01 ocaml:01 eray:01 ozkural:01 non-trivial:01 low-level:01 async:01 uniformly:01 arrays:01 implementer:01 arrays:01 compiler:01 pseudocode:01 eray:01 --Apple-Mail-1-889419888 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Maybe the solution is to get one of our numbers among the maintainers of = the shootout. This would guarantee, if not objectivity, then at least = informed choices wrt OCaml. On Nov 24, 2010, at 2:36 AM, Eray Ozkural wrote: > Hello, >=20 > I think that this benchmark is lacking in the algorithms department. = Where is a dynamic programming problem? A graph algorithm? Anything with = non-trivial time/space complexity? Anything a little more complex than = matrix product? >=20 > Also, it's not uncommon to disallow low-level optimizations such as = writing memory allocators and async file access when comparing = implementations of an algorithm, but such restrictions should be carried = out uniformly. In such a benchmark I would expect each entry to stick = to their guns, i.e. use only the standard libraries and programming = styles for instance. Linking in foreign libraries must most definitely = be disallowed. So, if in Java, it's necessary to call the garbage = collector explicitly from time to time, and we had to do that for a long = time, so be it. Or again, if in Java, performance will suffer unless you = only use arrays of integral types, the implementer may wish to implement = as much as is possible with arrays, though I wonder if it is not better = to choose the most natural implementation style for the particular = language. In the case of Java, the claim was that object-oriented was = some kind of a programming-aid that can replace talented programmers :) = It's unfortunate of course that some kinds of optimizations always have = to be made by hand, for instance in functional languages many compilers = do not have deforestation. >=20 > Otherwise, of course, any implementation may include a compiler for = the fastest language and present a program in that language, which is = not the objective. >=20 > An alternative objective could be to compare the shortest and most = comprehensible, if possible line-to-line compatible implementation of a = given pseudocode in different languages. That would be extremely = informative for serious algorithm researchers! If a computer scientist = isn't sure of the performance of the primitives, he cannot make sure his = implementation will comply with the time-complexity of the given = algorithm. >=20 > Best Regards, >=20 > On Wed, Nov 24, 2010 at 2:23 AM, Isaac Gouy wrote: >=20 >=20 >=20 > --=20 > Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, = Ankara > http://groups.yahoo.com/group/ai-philosophy > http://myspace.com/arizanesil http://myspace.com/malfunct >=20 > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --Apple-Mail-1-889419888 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello,

I think that this benchmark is lacking in = the algorithms department. Where is a dynamic programming problem? A = graph algorithm? Anything with non-trivial time/space complexity? = Anything a little more complex than matrix product?

Also, it's not uncommon to disallow low-level optimizations such as = writing memory allocators and async file access when comparing = implementations of an algorithm, but such restrictions should be carried = out uniformly.  In such a benchmark I would expect each entry to = stick to their guns, i.e. use only the standard libraries and = programming styles for instance. Linking in foreign libraries must most = definitely be disallowed. So, if in Java, it's necessary to call the = garbage collector explicitly from time to time, and we had to do that = for a long time, so be it. Or again, if in Java, performance will suffer = unless you only use arrays of integral types, the implementer may wish = to implement as much as is possible with arrays, though I wonder if it = is not better to choose the most natural implementation style for the = particular language. In the case of Java, the claim was that = object-oriented was some kind of a programming-aid that can replace = talented programmers :) It's unfortunate of course that some kinds of = optimizations always have to be made by hand, for instance in functional = languages many compilers do not have deforestation.

Otherwise, of course, any implementation may include a compiler for = the fastest language and present a program in that language, which is = not the objective.

An alternative objective could be to compare = the shortest and most comprehensible, if possible line-to-line = compatible implementation of a given pseudocode in different languages. = That would be extremely informative for serious algorithm researchers! = If a computer scientist isn't sure of the performance of the primitives, = he cannot make sure his implementation will comply with the = time-complexity of the given algorithm.

Best Regards,

On Wed, Nov 24, 2010 = at 2:23 AM, Isaac Gouy <igouy2@yahoo.com> = wrote:



--
Eray Ozkural, PhD = candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.c= om/group/ai-philosophy
http://myspace.com/arizanesil = http://myspace.com/malfunct
_______________________________________________
Caml-list mailing = list. Subscription management:
http://y= quem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: = http://caml.inria.fr
Beginner's list: = http://groups.yahoo.com/group/ocaml_beginners
Bug reports: = http://caml.inria.fr/bin/caml-bugs

= --Apple-Mail-1-889419888--