From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id B246DBC88 for ; Thu, 10 Feb 2005 15:54:30 +0100 (CET) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j1AEsUE0005407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2005 15:54:30 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1CzFi8-000CYq-K8 for caml-list@yquem.inria.fr; Thu, 10 Feb 2005 14:54:28 +0000 From: Jon Harrop Organization: University of Cambridge To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Memory allocation nano-benchmark. Date: Thu, 10 Feb 2005 14:56:13 +0000 User-Agent: KMail/1.7.1 References: <420B7A7E.90504@or.uni-bonn.de> In-Reply-To: <420B7A7E.90504@or.uni-bonn.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502101456.13367.jon@jdh30.plus.com> X-Miltered: at concorde with ID 420B75A6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 ocaml:01 iirc:01 run-time:01 polymorphism:01 polymorphism:01 arrays:01 error-prone:01 compiler:01 run-time:01 ...:98 frog:98 extensible:01 preprocessor:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Thursday 10 February 2005 15:15, Christian Szegedy wrote: > Let us look at another example where ocaml not really shines: > ... I brought this up a while ago. IIRC, performance is poor here because of: 1. Run-time polymorphism in Array.init. 2. Blitting the array twice (once for initialisation, once for filling). I believe the former could be fixed by running source through a whole-program preprocessor to remove all polymorphism. The latter could be addressed by extending the functionality of the GC to permit extensible arrays. However, this is tricky, error-prone work on a safety-critical part of the compiler. PS: Note that this is not a test of "memory allocation" as you state but, rather, it is mainly a test of the cost of run-time polymorphism. Remove the polymorphism for a better test of memory allocation. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd.