From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0FCfkHT015831 for ; Sat, 15 Jan 2011 13:42:04 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8AAF4lMU3RVdivkGdsb2JhbACcUwGICggVAQEBAQkJDAcRBCCkOIl6ghiEJS6GWgEBAwWFSwSLH4Ycgys X-IronPort-AV: E=Sophos;i="4.60,326,1291590000"; d="scan'208";a="95492463" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-MD5; 15 Jan 2011 13:41:46 +0100 Received: by qyk8 with SMTP id 8so338882qyk.6 for ; Sat, 15 Jan 2011 04:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OSSBXyN00hA9e9krSERj6MneJWkJkFMglsBPgkSL0fQ=; b=NomSJXLkCEyYLe9E8kg2SDGX4ayPaeA5mbbiVpzBd4bM4qcfQIUW4RliyG4W9TWgDf 8vbSGi5hXXBjuD6oUZ6MoYvQfuUyqV5OKA04DqBjFVMHfqxR9DC5GxU+9Ef9bIeVPcFy eLF+2CaK5RcPDdZdASAoqA/2gC1Qhwd49gzgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ZLvpQelaJv/7PRTn4oOdOhR9CC+FEAZwjptaGWglj594poWek6kjHgzz77NIeql5zd gfiN8lyHXDXVXsZMRNEAid5kkaaB4SbGvLaOorblQUNHe8ouEzRK3cxEvHIKooiVVUlP Oxe/nvR65Uh6WUznHcGU4sxPRY7+6njNK8MC8= Received: by 10.229.220.78 with SMTP id hx14mr1726119qcb.46.1295095304975; Sat, 15 Jan 2011 04:41:44 -0800 (PST) MIME-Version: 1.0 Sender: gabriel.scherer@gmail.com Received: by 10.229.23.139 with HTTP; Sat, 15 Jan 2011 04:41:24 -0800 (PST) In-Reply-To: References: From: bluestorm Date: Sat, 15 Jan 2011 13:41:24 +0100 X-Google-Sender-Auth: UJmcvf57OTXnxnxRUJroeVQlGJQ Message-ID: To: Eray Ozkural Cc: Caml List Content-Type: multipart/alternative; boundary=0016361e7f1c9a77390499e1df99 Subject: Re: [Caml-list] Unboxing: how to do it best? --0016361e7f1c9a77390499e1df99 Content-Type: text/plain; charset=ISO-8859-1 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 > > > --0016361e7f1c9a77390499e1df99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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
=A0=A0http://pauillac.inria.fr/~xleroy/talks/references-pldi98.html<= /div>
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


--0016361e7f1c9a77390499e1df99--