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 C4313BBAF for ; Tue, 23 Nov 2010 21:30:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEABez60xQW+UMgWdsb2JhbACBVZMOjgQVAQEWIiKIK6Ythy2JDIVLBIpe X-IronPort-AV: E=Sophos;i="4.59,243,1288566000"; d="scan'208";a="89207111" Received: from lo.gmane.org ([80.91.229.12]) by mail1-smtp-roc.national.inria.fr with ESMTP; 23 Nov 2010 21:30:18 +0100 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PKzUb-0000nK-JC for caml-list@inria.fr; Tue, 23 Nov 2010 21:29:33 +0100 Received: from c-24-4-7-10.hsd1.ca.comcast.net ([24.4.7.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 21:29:33 +0100 Received: from igouy2 by c-24-4-7-10.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 21:29:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Isaac Gouy Subject: Re: Is OCaml fast? Date: Tue, 23 Nov 2010 20:28:50 +0000 (UTC) Message-ID: References: <1290434674.16005.354.camel@thinkpad> <20101123.113733.2059974256209184038.Christophe.Troestler+ocaml@umons.ac.be> <1290540286.16005.411.camel@thinkpad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 24.4.7.10 (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12) X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 innocent:98 innocent:98 writes:01 tree:02 binary:02 binary:02 shootout:02 deallocate:03 benchmark:04 benchmark:04 debian:04 debian:04 Gerd Stolpmann gerd-stolpmann.de> writes: -snip- > I do not say that it is complete nonsense to do this comparison, but > only that it is more specific than a reader would assume. A reader's wrong assumptions are their own responsibility: http://shootou.alioth.debian.org/flawed-benchmarks.php > The innocent reader expects a comparison of binary tree performance, > not of methods of managing memory (and this is it finally). Perhaps rather than "innocent reader" you mean careless reader who didn't bother to read what the programs should do? http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=all#about > The true name of this test should be > "manage_many_small_memory_cells_where_pools_are_allowed". "binary-trees benchmark : Allocate and deallocate many many binary trees" > (It would be actually interesting to compare various versions of this test > with different memory management methods.) So do that comparison and publish the results.