From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id C8BF5BC6B for ; Thu, 31 May 2007 09:31:10 +0200 (CEST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4V7V8Ab030081 for ; Thu, 31 May 2007 09:31:09 +0200 Received: by an-out-0708.google.com with SMTP id b15so33386ana for ; Thu, 31 May 2007 00:31:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DelIiJmlfoNw6SyuZlIaRbnsRMceFR1DnI7gLi15UN9D2wPIMgnHPCPmROWv95TzlMlh5d4RiA/ZYpRIBFG/+0H2w8aSiw3mx+iPsnQQbWezDBBgKKv8rw5R8jeZGk4Kyl7niFdthTPv3gEQM/GRkUlMVvtL4SaQmfvDJZbCrPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pdqnD3P3S5BgxIH8Ortzcn3sn/3jvHYqr0pfZQ3hCY6cFdx7EkFY1xLpWWz2PjSL6yO07Yq2GJA6mkYtM8q75FPnFPRl/gk9QbECi7B2N58ylBA10Q4fMWAW9vHYKZ5eX8XY/GCwKyQxB7xl9rpvPiDhmewqNZWbR1OijAKtU7g= Received: by 10.78.123.4 with SMTP id v4mr208502huc.1180596664184; Thu, 31 May 2007 00:31:04 -0700 (PDT) Received: by 10.78.90.19 with HTTP; Thu, 31 May 2007 00:31:04 -0700 (PDT) Message-ID: <5195a210705310031n19f035e7sc5d96568e86496ae@mail.gmail.com> Date: Thu, 31 May 2007 15:31:04 +0800 From: "Yuanchen Zhu" Sender: yuanchen.zhu@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics In-Reply-To: <200705310717.01553.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <200705310717.01553.jon@ffconsultancy.com> X-Google-Sender-Auth: fface0af3025d28c X-Miltered: at discorde with ID 465E79BC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 wget:01 unpack:01 parses:01 sml:01 fft:01 high-level:01 ocamlopt:01 unrolling:01 4.5:98 compile:01 caml-list:01 tar:01 unsafe:01 > > The new running time is: > > > > Ocaml (unsafe) : user: 21.477s, real: 23.366s > > What is the running time for safe OCaml? Safe OCaml adds another 4.5s. > > > which is much in line with MLton: > > > > MLton (safe): user: 17.981s, real: 21.968s > > What platforms and architectures did you benchmark on? May we have the code to > benchmark it ourselves? I am on a Pentium M 1.8GHz with 1GB mem, running Ubuntu 7.04, with mlton_20061107 and ocaml 3.09.2. I've packed the code and uploaded it at: http://www.people.fas.harvard.edu/~yzhu/hdrRc.tar.bz2 Just wget it and unpack, go into the hdrRc directory, and run ./build-and-test.sh. Take a look at build-and-test.sh for the build and test parameters. I couldn't get Mlton to include the SMLNJ-lib's ArrayQSort module, so I just copied the file containing it into the same directory. Also, the Ocaml version parses its parameters (using the incredibly helpful Arg module) so the executable requires some extra argument. The SML version just hard code the parameters. > You might also try an FFT-based convolution if your filter is dense. It's true that I might be able to get better performance using FFT, or even using a GPU based convolution, if I'm willing to invest a lot more time and energy. But wouldn't it be nice to be able to write in terse high-level style, but at the same time be able to compile it to exectuable with performance close to C? > > This brings me to the next question: is there any plan to implement > > type specialization optimization for ocamlopt? For numerics, this is > > really crucial if you want write both in an elegant functional style > > and get good performance. Also, I remember reading somewhere that the > > current code base of Ocaml is ill-suited for implementing this kind of > > optimization. May I ask what exactly needs to be done to the current > > code base in order to support that? I have some compiler-writing > > background and this sounds like an interesting project to work in my > > past time. > > Writing OCaml programs that generate OCaml programs is by far your best bet > here. We use a replacement standard library that uses autogenerated code to > eliminate boxing and perform unrolling and type specialization where > possible. > > As I can autogenerate my code, I would much rather the OCaml developers > concentrated on things that I cannot get around, like the lack of a 32-bit > float storage type and a more efficient internal representation of complex > numbers. That sounds very interesting. Could you elaborate or give an example?