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 7E92BBBAF for ; Mon, 22 Nov 2010 15:36:53 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBABYP6kzRVaG0k2dsb2JhbACaSogFCBUBAQEBCQkKCREDH4grmlGJY4IYhHQuiFkBAQMFhUYEil6JLQ X-IronPort-AV: E=Sophos;i="4.59,236,1288566000"; d="scan'208";a="79972814" Received: from mail-gx0-f180.google.com ([209.85.161.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 15:36:52 +0100 Received: by gxk24 with SMTP id 24so962810gxk.39 for ; Mon, 22 Nov 2010 06:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=gAa0BPBFcc0MSQtlnQ4VvFhoBrnOQjJ9XY2n2jTDDhE=; b=GBma5e52MHZb2rgUYYe0XWHe/2Bh7qr8E7NAOgUqJvnqemdUNKJfOKWxyWMb4u6uPI ybwwWmAmmlwJjXI3tuhbJTp2mAQwqhblgIiyGHL9ELfbSeszICA7jHC4R27xxVYqyCc9 W8KoYxGU98CPoIBphS83f/vUwL/z9ZMBMr6ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=e03638HToGLIx93AFMJiYEolxaTesk5NT140Yr28aIqQxQ8WYegja0jox0XtQwlNNs VjOovcDytxlh6Z6iL8QmqJ4DKOJHndCSP5lV0WVeGvVsd2b9Cz2nBdxUgTnEoMSx5yA4 5ebBFbUHTFND7oliyRxiL9OkWMejQlmSfI8uw= Received: by 10.229.217.133 with SMTP id hm5mr4990022qcb.258.1290436610295; Mon, 22 Nov 2010 06:36:50 -0800 (PST) MIME-Version: 1.0 Sender: gabriel.scherer@gmail.com Received: by 10.229.253.135 with HTTP; Mon, 22 Nov 2010 06:36:30 -0800 (PST) In-Reply-To: <1290434674.16005.354.camel@thinkpad> References: <1290434674.16005.354.camel@thinkpad> From: bluestorm Date: Mon, 22 Nov 2010 15:36:30 +0100 X-Google-Sender-Auth: RzKmJDYH24FRmp_YXa1T6ujnLrk Message-ID: Subject: Re: [Caml-list] Is OCaml fast? To: Gerd Stolpmann Cc: Thanassis Tsiodras , caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016361e81a2c30ada0495a52f01 X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 ocaml:01 gerd:01 stolpmann:01 sans-serif:98 sans-serif:98 wrote:01 wrote:01 heap:01 heap:01 verdana:98 verdana:98 caml-list:01 --0016361e81a2c30ada0495a52f01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann wro= te: > I think the shootout is not a good data source. There are definitely > some very poor Ocaml results there, so I'd guess the shootout got > recently more attention by enthusiasts of other languages, and the > current Ocaml programs there are not very good. (I remember Ocaml was #1 > at the shootout a few years ago, faster than C.) So maybe a good > opportunity to post better Ocaml solutions there? > As Sylvain noticed, some (in not most) of the OCaml poor performances in th= e shootout are actually not due to bad OCaml programs, but to arbitrary restrictions in the shootout rules. For example, one of the bad-performing benchmark for OCaml is the binary-tree benchmark, where it is nearly four times slower than C, but on closer inspection you discover that this is due to the arbitrary choice to forbid any change of the GC parameters. With appropriate GC parameters, the very same OCaml program is exactly as fast a= s C. http://shootout.alioth.debian.org/u32/performance.php?test=3Dbinarytrees =AB Note: these programs are being measured with *the default initial heap size* - the measurements may be very different with a larger initial heap size or GC tuning. =BB C version : 12.11 secs OCaml version : 47.22 secs OCaml version with GC parameters tuned ("interesting alternative" section) = : 12.67 secs Therefore, there is nothing that can be changed to the OCaml submission for this benchmark to improve performances, except changing the default GC parameters; while this might be a good idea in general, changing it only fo= r the sake of shootout-obsessed people is ridiculous. --0016361e81a2c30ada0495a52f01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann <info@gerd-stolpmann.de> = wrote:
I think the shootout is not a good data source. There are definitely
some very poor Ocaml results there, so I'd guess the shootout got
recently more attention by enthusiasts of other languages, and the
current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good
opportunity to post better Ocaml solutions there?

=
As Sylvain noticed, some (in not most) of the OCaml poor perform= ances in the shootout are actually not due to bad OCaml programs, but to ar= bitrary restrictions in the shootout rules. For example, one of the bad-per= forming benchmark for OCaml is the binary-tree benchmark, where it is nearl= y four times slower than C, but on closer inspection you discover that this= is due to the arbitrary choice to forbid any change of the GC parameters. = With appropriate GC parameters, the very same OCaml program is exactly as f= ast as C.


=AB=A0N= ote: these programs are being measured with=A0the default initial heap = size=A0- the measurements may be very different with a larger initial = heap size or GC tuning. =BB
C= version : 12.11 secs
OCaml version : 47.22 secs
OCam= l version with GC parameters tuned ("interesting alternative" sec= tion) : 12.67 secs
<= br>

Therefore, there is nothing that can be cha= nged to the OCaml submission for this benchmark to improve performances, ex= cept changing the default GC parameters; while this might be a good idea in= general, changing it only for the sake of shootout-obsessed people is ridi= culous.
--0016361e81a2c30ada0495a52f01--