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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D2154BB81 for ; Thu, 15 Dec 2005 16:09:40 +0100 (CET) Received: from [128.93.11.95] (estephe.inria.fr [128.93.11.95]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jBFF9d24008962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2005 16:09:39 +0100 Message-ID: <43A18732.2060201@inria.fr> Date: Thu, 15 Dec 2005 16:09:38 +0100 From: Xavier Leroy User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerd Stolpmann Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comments welcomed to progr. style / speed of my first ocaml program "Error correcting LDPC decoder" References: <3943.192.168.1.2.1134648180.squirrel@gps.dynxs.de> <3518.192.168.1.2.1134650422.squirrel@gps.dynxs.de> In-Reply-To: <3518.192.168.1.2.1134650422.squirrel@gps.dynxs.de> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43A18733.004 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 hacks:01 element:02 types:02 seems:03 float:03 uniform:03 let:03 profiling:04 layout:05 inria:05 style:93 xavier:06 xavier:06 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 > I forgot one thing: This comment is only correct for 32 bit code. 64 bit > code has a uniform array layout for all element types. Yes, but a generic access to a float array still involves an extra boxing operation. So, your advice is sound for 64-bit plaforms as well. I had a very quick look at the original poster's code: it seems reasonable performance-wise. There are a few extra hacks that could be done to increase performance at some expense in code clarity, for instance turning a.(i).(j) <- f i j a.(i).(j); in (let b = a.(i) in b.(j) <- f i j b.(j)); but I wouldn't recommend doing this unless profiling exhibits a big "hot spot" in this function. - Xavier Leroy