From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0FDbqq4018079 for ; Sat, 15 Jan 2011 14:37:52 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUAAI4xMU3RVdW2k2dsb2JhbACWHoY1AYgKCBUBAQEBCQkKCREEIKQbiXqCGIQnLoZaAQEDBYVLBIsfhhw X-IronPort-AV: E=Sophos;i="4.60,327,1291590000"; d="scan'208";a="86987662" Received: from mail-yx0-f182.google.com ([209.85.213.182]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2011 14:37:46 +0100 Received: by yxh35 with SMTP id 35so1504286yxh.27 for ; Sat, 15 Jan 2011 05:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b/iKDDOJ+6G4qOP5xRcSEJg+4BxKHUgS4Uuhe8ouWpU=; b=RwPQktFEcUNrawrMW+jUKee40+o32YmIv+4mFQgojgW0IbxRuTGzhP5yOrLCJuviif WGcC+g0xDjvq4FU+qLnjz3DTSEy7jJaT9w5T2EdqgE6w+GDMGXGxyZLp3SCzpu3PgL9V xFMWyaUOEJ6E8t2QUBAFMuRGkO3QSdbvYad3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jqjz7jX+JEM5oTrnmQULFBMo8qby1aLUQX5JwG/1joRbZSKNeFHoB/Ge+hl7+BJ1jw qv1uL9oHyvtDG7LVatqAUzdQBWPryjwgIgPlFuCf4UP5Rp9Sy0rh0W1en3ExKnXEiHqg vuUa4t4eeOai00EPaKVv3+cBpupkY+dcuSY/k= MIME-Version: 1.0 Received: by 10.90.118.2 with SMTP id q2mr2520730agc.11.1295098664789; Sat, 15 Jan 2011 05:37:44 -0800 (PST) Received: by 10.90.89.4 with HTTP; Sat, 15 Jan 2011 05:37:44 -0800 (PST) In-Reply-To: References: Date: Sat, 15 Jan 2011 15:37:44 +0200 Message-ID: From: Eray Ozkural To: bluestorm Cc: Caml List Content-Type: multipart/alternative; boundary=0016362836e8dd2a970499e2a7a5 Subject: Re: [Caml-list] Unboxing: how to do it best? --0016362836e8dd2a970499e2a7a5 Content-Type: text/plain; charset=ISO-8859-1 Except that ocaml is hardly a slow scripting language, on many levels it's directly comparable to C++ code. In my opinion, ocaml should be usable all the way down to the kernel code. For many complex algorithms and data structures, using C++ with all the zero-overhead level-headed template-bloated pages-long low-level intricate imperative code you'll get a very small constant factor improvement. For an actual non-trivial search code I got only twice the speed of the ocaml code, even though I used vectors instead of lists throughout. Not worth the effort at all. I wouldn't even attempt it if I hadn't had to port the code to C++. Thanks for the references by the way, I am actually interested in this. I'm thinking of its extensions (i.e. distributed memory architectures, shared memory cannot scale anyway). Best, On Sat, Jan 15, 2011 at 2:41 PM, bluestorm wrote: > I don't think it is easily possible inside Caml, as the data representation > is tightly bound to the runtime system, and it would be very delicate to > change it. > > If you are interested in the relevant litterature, you may want to see for > example the bibliography on "Unboxing data representations" of > http://pauillac.inria.fr/~xleroy/talks/references-pldi98.html > In particular, you may be interested in the Peyton-Jones and Launchbury > paper, as they implemented their ideas into the GHC Haskell compiler which > support some unboxed types. > > If you want to optimize the kernel of an existing OCaml program with > unboxed manipulations, I think your best bet would be to switch to a > lower-level language for your kernel. This is very common in scripting > languages where you generally implement the -- hopefully tiny -- > performance-sensitive parts of your program in C. You still reap the > benefits of OCaml abstractions for the larger, less performance-sensitive > part of your program. > > > On Sat, Jan 15, 2011 at 1:02 PM, Eray Ozkural wrote: > >> It's obvious that avoiding pointer chasing, improving locality and >> reducing storage will in some cases improve performance considerably. I've >> found many discussions about unboxing, but I haven't seen any solutions that >> would satisfy high-performance-computing programmers, who would probably >> like to have better (i.e. fine-grained) control over memory layout (unboxing >> double arrays isn't enough). In C++ this is trivial, because C++ is just an >> abstraction of assembly code. To cut it short, could not we have basically >> the same affordances of C++ in ocaml by annotating type definitions to >> indicate where unboxing would be forced? Such annotations aren't a new idea >> in programming languages, specifically HPF was based largely on parallel >> storage annotations. >> >> Regards, >> >> -- >> Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara >> >> >> > -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct --0016362836e8dd2a970499e2a7a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Except that ocaml is hardly a slow scripting language, on many levels it= 9;s directly comparable to C++ code. In my opinion, ocaml should be usable = all the way down to the kernel code. For many complex algorithms and data s= tructures, using C++ with all the zero-overhead level-headed template-bloat= ed pages-long low-level intricate imperative code you'll get a very sma= ll constant factor improvement. For an actual non-trivial search code I got= only twice the speed of the ocaml code, even though I used vectors instead= of lists throughout. Not worth the effort at all. I wouldn't even atte= mpt it if I hadn't had to port the code to C++.

Thanks for the references by the way, I am actually interest= ed in this. I'm thinking of its extensions (i.e. distributed memory arc= hitectures, shared memory cannot scale anyway).

Best,

On Sat, Jan 15, 2011 at 2:41 PM, bl= uestorm <b= luestorm.dylc@gmail.com> wrote:
I don't think it is easily possible inside Caml, as the data representa= tion is tightly bound to the runtime system, and it would be very delicate = to change it.

If you are interested in the relevant litt= erature, you may want to see for example the bibliography on "Unboxing= data representations" of
In particular, you may be interested in the Peyton-Jones and Launchbury pap= er, as they implemented their ideas into the GHC Haskell compiler which sup= port some unboxed types.

If you want to optimize t= he kernel of an existing OCaml program with unboxed manipulations, I think = your best bet would be to switch to a lower-level language for your kernel.= This is very common in scripting languages where you generally implement t= he -- hopefully tiny -- performance-sensitive parts of your program in C. Y= ou still reap the benefits of OCaml abstractions for the larger, less perfo= rmance-sensitive part of your program.


On Sat, Jan 15, 2011 at = 1:02 PM, Eray Ozkural <examachine@gmail.com> wrote:
It's obvious that avoiding pointer chasing, improving locality and redu= cing storage will in some cases improve performance considerably. I've = found many discussions about unboxing, but I haven't seen any solutions= that would satisfy high-performance-computing programmers, who would proba= bly like to have better (i.e. fine-grained) control over memory layout (unb= oxing double arrays isn't enough). In C++ this is trivial, because C++ = is just an abstraction of assembly code. To cut it short, =A0could not we h= ave basically the same affordances of C++ in ocaml by annotating type defin= itions to indicate where unboxing would be forced? Such annotations aren= 9;t a new idea in programming languages, specifically HPF was based largely= on parallel storage annotations.

Regards,

--
Eray Ozkural, PhD = candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara





--
Eray Ozkura= l, PhD candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/g= roup/ai-philosophy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--0016362836e8dd2a970499e2a7a5--