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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id CCCCABBAF for ; Wed, 24 Nov 2010 02:36:30 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgADAEj760xKfVM2kGdsb2JhbACUOYYoAYc2TggVAQEBAQkJDAcRAx+jUIlkghiFCC6IWQEBAwWFRgSBXIkChX4 X-IronPort-AV: E=Sophos;i="4.59,245,1288566000"; d="scan'208";a="80080298" Received: from mail-gw0-f54.google.com ([74.125.83.54]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Nov 2010 02:36:30 +0100 Received: by gwj21 with SMTP id 21so7671234gwj.27 for ; Tue, 23 Nov 2010 17:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kKC9FfVCTxU2Mw9QDy7yrISSPg1QlkQLS+ymrDbQRM8=; b=aNfa8c9p7lfIaedmVPu+8/vnOv1VLdNCy7aFcGN6yHU/4YUaj7b3hH9iDwGNufj9sO 2iHC7TrcHxBPSuPSZg/A9irJZL1amvrQcbJHagy1kC9EBmA/FvxUOK1YET7AVOGnkO3C vlKGnOyyTpSjlo1N9kONbVm0nfMfKxczYz+vc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KMNzvKnPbW0nR4JTNsJPcrOCOFeWDoYnH1bgev98DSWq8YDDxpkw5TZJJr3+mh7CjX VfKfI9caGm73yUhOI5sSnwDZTo77nsOaS+fkV1q0H6rK+3AZ0AKeRKxf10uPFVveEJqd mwmhvPuZqWAtBNO+XgXYMVs0fNCcOw4kmL1UM= MIME-Version: 1.0 Received: by 10.90.4.34 with SMTP id 34mr9635720agd.140.1290562588119; Tue, 23 Nov 2010 17:36:28 -0800 (PST) Received: by 10.91.154.3 with HTTP; Tue, 23 Nov 2010 17:36:27 -0800 (PST) In-Reply-To: References: <1290434674.16005.354.camel@thinkpad> <20101122180203.2126497sau3zukgb@webmail.in-berlin.de> <20101123232742.GC28768@siouxsie> Date: Wed, 24 Nov 2010 03:36:27 +0200 Message-ID: Subject: Re: [Caml-list] Re: Is OCaml fast? From: Eray Ozkural To: Isaac Gouy Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=0016363105d1a014890495c28492 X-Spam: no; 0.00; 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 in-berlin:01 beginner's:01 ocaml:01 --0016363105d1a014890495c28492 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > first.in-berlin.de> writes: > > > > Even back in 2001, Doug Bagley had noted all the things that were > > > wrong with the tasks on his "The Great Computer Language Shootout". > > > > And what was wrong in his eyes? > > Find out for yourself: > > http://web.archive.org/web/20010617014807/www.bagley.org/~doug/shootout/ > > > > So, now the comparisions are perfect? > > Has anyone said so? > > > > What problems were removed? > > All of them. > > _______________________________________________ > 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 > -- 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 --0016363105d1a014890495c28492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

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

Also, it's not uncommon to disallow low-level optimizations such as= writing memory allocators and async file access when comparing implementat= ions of an algorithm, but such restrictions should be carried out uniformly= .=A0 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. L= inking in foreign libraries must most definitely be disallowed. So, if in J= ava, 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 J= ava, performance will suffer unless you only use arrays of integral types, = the implementer may wish to implement as much as is possible with arrays, t= hough I wonder if it is not better to choose the most natural implementatio= n style for the particular language. In the case of Java, the claim was tha= t object-oriented was some kind of a programming-aid that can replace talen= ted programmers :) It's unfortunate of course that some kinds of optimi= zations always have to be made by hand, for instance in functional language= s 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 implementatio= n of a given pseudocode in different languages. That would be extremely inf= ormative for serious algorithm researchers! If a computer scientist isn'= ;t sure of the performance of the primitives, he cannot make sure his imple= mentation 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:
=A0<oliver <at> first.in-berlin.de> writes:

> > Even back in 2001, Doug Bagley had noted all the things that were=
> > wrong with the tasks on his "The Great Computer Language Sho= otout".
>
> And what was wrong in his eyes?

Find out for yourself:

http://web.archive.org/web/20010617014807/www= .bagley.org/~doug/shootout/


> So, now the comparisions are perfect?

Has anyone said so?


> What problems were removed?

All of them.

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs



--
Eray Ozkura= l, PhD candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/g= roup/ai-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--0016363105d1a014890495c28492--